Re: "Fix" sag scaling for hidpi

[Yuan Fu <casouri@gmail.com>]

> On Feb 13, 2021, at 10:08 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Alan Third <alan@idiocy.org> writes:
> 
>> Ah, I've misunderstood how GTK deals with scaling. I could've sworn
>> someone said upthread that SVG images are shown at double size, the
>> same as on macOS, but apparently not.
> 
> I tried loading the splash.svg file, and it's displayed here the same
> size as the splash.png file.  Debian bullseye, HiDPI, scaling factor of
> 2.3, so the 333-pixel-wide image is displayed as a 760-pixel-wide image:

What does this scaling factor do? Is it some sort of global GTK setting that makes it work with hidpi screens?

> 
> (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.png"))
> (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.svg"))
> 
>> So we have the situation where on macOS everything is shown at logical
>> size, unless you specifically ask for it not to be, and on GTK
>> everything is shown at physical size, unless you ask for it not to be.
>> 
>> And they both use "scale factor" for these same things.
>> 
>> What does the PGTK port do? The same as XGTK?
> 
> This is a Gtk Emacs, but not a pgkt Emacs -- I haven't tried the pgtk
> branch...
> 
>> Nope, it's the same as on macOS.
>> 
>> So on macOS and PGTK we want to use the scale factor to scale down
>> images so they are displayed with physical pixels, and on XGTK we want
>> to scale up (UI?) images so they are displayed in logical pixels.
>> 
>> I'm somewhat inclined to ignore XGTKs desires, especially as it seems
>> it may be removed once PGTK is merged.
> 
> It sounds like confusion born out of some architectures reporting sizes
> as logical pixels, and some as physical pixels.  That has to be fixed,
> or we'll just confuse ourselves even more.  :-)

I agree. Currently macOS and PGTK reports logical pixel sizes and other terminals report physical ones. We should make all terminal report logical sizes, then we don’t need image-scaling-factor anymore.

> 
>>> Uhm...  but on Macos, Emacs doesn't know the physical pixel size, I
>>> think you said earlier?  So...  er...  now I'm confused.  :-)
>> 
>> It's something you have to go looking for specifically, usually
>> through multiplying by the scale factor. The reason I said I wouldn't
>> want Emacs to convert everything to physical pixels is because every
>> single size would have to be multiplied or divided by the scale
>> factor, and then Emacs would appear to be half the size of every other
>> app (font sizes would be half what they are in the terminal, for
>> example).
> 
> I don't follow.  This Gtk Emacs is exactly the size I want it to be, and
> it computes everything in physical pixels.

Using logical pixels works better, I think. One, it doesn’t require people with hidpi screens to use a huge font size and rely on image-scaling-factor to scale UI icons; two, Emacs frame size will not change drastically if you drag it between hidpi screen and normal screen; three, it seems Mac, windows and gtk all support logical pixels, for me it’s TRT to do.

> 
> If the OS expects logical pixels, then we scale before asking the OS to
> do something -- this is how Gtk menus are computed, for instance.
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no

Yuan