emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yuri Khan
Subject: Re: What is the proper way to scale fringe-bitmaps for high-DPI displays?
Date: Thu, 21 Mar 2019 20:33:33 +0700

On Thu, Mar 21, 2019 at 6:50 PM Daniel Pittman <address@hidden> wrote:
>> 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.

I hear GTK+/Wayland also has this ability. Never tried it though.
GTK+/X is as far as I know constant DPI over the whole X display.

> 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?

I can see the following options:

* Migrate everything to SVG. Teach developers SVG is good, bitmaps are
bad. Package developer provides a single vector image. Failure mode:
developer is on a high DPI screen, makes a high-detail image, low DPI
users complain “image is blurry”.

* Keep bitmaps and upscale them for high DPI. Package developer
provides a single bitmap image. Failure mode 1: Nearest neighbor
upscaling looks ugly at non-integer factors. Failure mode 2: all other
upscaling algorithms look ugly pretty much always.

* Keep bitmaps and downscale them for low DPI. Package developer
provides a single, fairly large bitmap image. Failure mode: small
details get lost on low resolutions, image looks blurry.

* Migrate to multi-resolution bitmaps. Package developer has to
provide multiple bitmaps. Failure mode 1: Nobody knows what sizes they
need. Failure mode 2: Some will only include one for the low DPI. This
can be combined with up/downscaling, trading the corresponding failure
modes around.


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

Actually, the HTML pixel is specified as 1/96 of an inch.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]