> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 20 Mar 2019 17:17:16 -0400
>
> >> Oh, so Emacs' C code would scale the bitmaps? I expected the Lisp code would do that.
> >
> > Fringes are displayed in C. Doing this in Lisp will produce
> > flickering, I'm afraid.
>
> I thought the C code would read the scaling factor and set the bitmap accordingly just once, when creating overlays or applying text properties.
But you were saying that a frame can move from a high-DPI terminal to
a low-DPI one, which seems to mean we cannot compute that just once.
They can, at least on macOS, where that is entirely trivial to achieve by plugging an external (low DPI) monitor into a (high DPI) laptop with the panel open. You could even enjoy the fun situation where your frame is displaying half the window on each of them, so technically has two different and concurrent densities.
And besides, there are fringe bitmaps that we display regardless of
any overlays and text properties (e.g., truncation and continuation
indicators), which are displayed directly from C.
What you really want here is a resolution independent unit for specifying the size of the output, or a macOS-alike ability to give multiple resolution bitmaps and have the most appropriate selected by Emacs, yeah? Anyway, I'd certainly say that having the C code scale the bitmap is the most reasonable "no changes to anything else" solution – macOS did that during the early transition to those high density displays, and it worked out pretty well overall. (Though they have a rendering model vastly less tied to physical units than most things.)
As a potentially useful aside in this context, HTML specifies that the "pixel" is a resolution-independent unit, and should probably approximate a 72 DPI display as the 1:1 logical:physical device. I mention this because applying similar logic in Emacs would give the closest approximation of what people have been trained to expect in other media. (Though the choice to not scale the content of the img tag... was not great.)