Re: What is the proper way to scale fringe-bitmaps for high-DPI displays?

[Daniel Pittman <slippycheeze@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]

On Thu, Mar 21, 2019 at 3:32 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > 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.)

[-- Attachment #2: Type: text/html, Size: 2915 bytes --]