emacs-devel
[Top][All Lists]
Advanced

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

Re: "Fix" sag scaling for hidpi


From: Alan Third
Subject: Re: "Fix" sag scaling for hidpi
Date: Sat, 13 Feb 2021 15:59:38 +0000

On Sat, Feb 13, 2021 at 04:08:34PM +0100, Lars Ingebrigtsen 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:
> 
> (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.png"))
> (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.svg"))

Strange. When I do that with GDK_SCALE=2 I get both images as 333
pixels wide. The only thing that appears to have been scaled are the
menus and toolbar, everything else is the exact same size as if I use
GDK_SCALE=1.

I guess I'm doing something wrong.

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

It's not really a problem in practice unless you want images that
aren't blurry due to being scaled up.

The confusion I'm seeing is purely down to the XGTK emacs scaling only
some UI elements.

(It does look like Windows is confusing though, since the first page
I've landed on to explain how it works describes three completely
separate mechanisms, one of which appears to match what macOS and GTK
do, while two are completely different.)

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

I'd stick with the default behaviour and just work around the few
occasions where that results in unwanted behaviour (the previously
mentioned blurry images).

-- 
Alan Third



reply via email to

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