Non-integral scaling factors: best practices?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Non-integral scaling factors: best practices?

Brion Vibber
GTK+3 added native support for user interface scaling to support HiDPI displays with consistently sized resources and widgets, with the limitation that the scaling factor is an integer (1x, 2x, 3x...)

This seemed a good bet when the earliest HiDPI iOS, MacOS and ChromeOS machines all came out at 2x, and holds for many high-end PCs... However, PC laptops with 1920x1080 screens that need a 1.5x or so scaling factor are now quite common, and a lot of people have CC'd themselves on this old bug asking about it: https://bugzilla.gnome.org/show_bug.cgi?id=720502

This also means non-integral scaling factors are common on Windows, which may affect cross-platform apps using a GTK+ front-end.

Is there anything that could be done in the GTK+ 4 dev cycle to better support non-integral scaling factors? I don't know if it's either feasible or desirable to just rip out the integers and replace with floats...


Alternately, would it make sense to recommend best practices for applications to make display sizes of non-text elements scale along with the font scaling factor?

For instance, there might be a recommendation that a 1x window scaling factor with a 1.5x font scaling factor should scale icons, buttons, toolbars etc in their units by 1.5x. There may also need to be a consistent way to load image resources at intermediate scales (or a recommendation to load the 2x resources and scale down).

This would result in apps at (window 1x, font 1.5x) would look about the same as they would have if (window 1.5x, font 1x) were supported... But might be a change for people who specifically wanted larger text but not larger icons and other widgets. Would that be likely to be problematic?


Thanks for any feedback and ideas -- and thanks everybody for all your work on making GTK+ an awesome toolkit for Linux (and cross-platform) apps!

-- brion

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-integral scaling factors: best practices?

Emmanuele Bassi
On 27 April 2017 at 22:56, Brion Vibber <[hidden email]> wrote:
> GTK+3 added native support for user interface scaling to support HiDPI
> displays with consistently sized resources and widgets, with the limitation
> that the scaling factor is an integer (1x, 2x, 3x...)

It's not really a "limitation": it's purposefully designed that way,
for windowing system surfaces and graphical assets. Font sizes support
fractional values, and have been doing so for a long while (since the
GTK+ 2.x days)

In general, the toolkit has no code to detect scaling factors at all,
and it relies on the system to convey meaning to those values.

> This seemed a good bet when the earliest HiDPI iOS, MacOS and ChromeOS
> machines all came out at 2x, and holds for many high-end PCs... However, PC
> laptops with 1920x1080 screens that need a 1.5x or so scaling factor are now
> quite common, and a lot of people have CC'd themselves on this old bug
> asking about it: https://bugzilla.gnome.org/show_bug.cgi?id=720502

To be fair, 1080p displays with higher-than-192 DPI densities are a
temporary oddity, and are being phased out to the lower end of the
spectrum by HiDPI displays on laptops, and by 4K and 5K displays on
desktops. The cost is still high, but we (Endless) have already
started seeing HiDPI panels in laptops that are starting to target
emerging markets In general, desktop environments will keep a scaling
factor of 1x on 1080p displays, regardless of DPI density. Changing
the font-scaling factor to increase the font size is a valid solution;
for instance, GNOME could keep the window scaling factor to 1x and
make fonts 1.25x bigger if it detects a 1080p display.

> This also means non-integral scaling factors are common on Windows, which
> may affect cross-platform apps using a GTK+ front-end.
>
> Is there anything that could be done in the GTK+ 4 dev cycle to better
> support non-integral scaling factors? I don't know if it's either feasible
> or desirable to just rip out the integers and replace with floats...

No, it's not desirable.

Windowing system surfaces cannot be "half pixel" in size; graphical
assets and fonts positioned or sized with sub-pixel precision will
appear blurry and won't look right.

The appropriate way to do fractional scaled rendering at 1.5x is to
render at 3x scale, and have the compositor downscale by a factor of
2x; this is also what macOS does. Of course, this needs cooperation
from the windowing system, as the scaling must also affect the input.
This is why, on Linux, we're going to rely on Wayland compositors to
do the right thing (X11, sadly, cannot do input transformations).

> Alternately, would it make sense to recommend best practices for
> applications to make display sizes of non-text elements scale along with the
> font scaling factor?

Applications shipping assets should ensure to have *at least* 2x
scaled images, and should be coded defensively in case the scaling
factor is >2x; they should also always ensure that everything is pixel
grid aligned when positioning and sizing assets manually, instead of
using the toolkit layout managers.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-integral scaling factors: best practices?

Brion Vibber
On Thu, Apr 27, 2017 at 3:58 PM, Emmanuele Bassi <[hidden email]> wrote:
To be fair, 1080p displays with higher-than-192 DPI densities are a
temporary oddity, and are being phased out to the lower end of the
spectrum by HiDPI displays on laptops, and by 4K and 5K displays on
desktops. The cost is still high, but we (Endless) have already
started seeing HiDPI panels in laptops that are starting to target
emerging markets

Good news! :)
 
In general, desktop environments will keep a scaling
factor of 1x on 1080p displays, regardless of DPI density. Changing
the font-scaling factor to increase the font size is a valid solution;
for instance, GNOME could keep the window scaling factor to 1x and
make fonts 1.25x bigger if it detects a 1080p display.

*nod* I've done this manually on Linux laptops in the past. At 1.25x it's not too bad, but at 1.5x many widgets and icons are visibly smaller than expected because they don't get scaled along with the font size. This is usually ok, though icons can be hard to click and occasionally text in small widgets overflows.
 
> I don't know if it's either feasible
> or desirable to just rip out the integers and replace with floats...

No, it's not desirable.

Windowing system surfaces cannot be "half pixel" in size; graphical
assets and fonts positioned or sized with sub-pixel precision will
appear blurry and won't look right.

Gotcha. :)
 
The appropriate way to do fractional scaled rendering at 1.5x is to
render at 3x scale, and have the compositor downscale by a factor of
2x; this is also what macOS does. Of course, this needs cooperation
from the windowing system, as the scaling must also affect the input.
This is why, on Linux, we're going to rely on Wayland compositors to
do the right thing (X11, sadly, cannot do input transformations).

Great; that'll be awesome on Linux once supported throughout the stack consistently.

My main remaining concern would be cross-platform GTK+ apps on Windows. Windows uses compositor & input scaling to display non-HiDPI-aware apps scaled up as necessary, but I'm not sure offhand if one can override it to do things like downscaling a 3x rendering to 1.5x display. Sticking with integral window scaling plus non-integral font scaling for that would keep things simpler.

I haven't seen a lot of GTK+3 apps with Windows ports yet, but I often use both GIMP and Inkscape (GTK+2) on various OSs and I believe both have GTK+3 migrations coming along.
 
> Alternately, would it make sense to recommend best practices for
> applications to make display sizes of non-text elements scale along with the
> font scaling factor?

Applications shipping assets should ensure to have *at least* 2x
scaled images, and should be coded defensively in case the scaling
factor is >2x; they should also always ensure that everything is pixel
grid aligned when positioning and sizing assets manually, instead of
using the toolkit layout managers.

Should application developers try to scale widgets according to the font scale, such as using 'em' or 'rem' units in CSS? Or should we just accept that a lot of widgets (especially those with bitmap icons) will appear small in the 1.5x font-scale scenario for now?

Thanks!

-- brion

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MacOS Text Scaling

John Ralls-2
In reply to this post by Emmanuele Bassi

On Apr 27, 2017, at 3:58 PM, Emmanuele Bassi <[hidden email]> wrote:

On 27 April 2017 at 22:56, Brion Vibber <[hidden email]> wrote:
GTK+3 added native support for user interface scaling to support HiDPI
displays with consistently sized resources and widgets, with the limitation
that the scaling factor is an integer (1x, 2x, 3x...)

It's not really a "limitation": it's purposefully designed that way,
for windowing system surfaces and graphical assets. Font sizes support
fractional values, and have been doing so for a long while (since the
GTK+ 2.x days)

In general, the toolkit has no code to detect scaling factors at all,
and it relies on the system to convey meaning to those values.

This might be a bit of a digression, sorry.

Gdk has several scaling-dependent functions:  gdk_screen_(set|get)_resolution(), gdk_monitor_get_scale_factor, and gdk_(screen|monitor)_get_(height|width)_mm()
and I'm trying to figure out how to get the right behavior on MacOS HiDPI (aka retina) monitors. A couple of weeks ago I replaced an obsolete function ([NSScreen userSpaceScaleFactor]) [1] with a more-correct implementation that effectively does what it's supposed to, return 144dpi for retina and 72 for normal. Doing so causes the font-size to double; i.e. a 12-point font displays at 24-points.

I suspect that's because Pango calls gdk_screen_get_resolution(), but it also uses Apple's CoreText for rendering and layout on MacOS and I suspect that CoreText is already compensating for the retina screen, resulting in the doubled font scaling. Does that make sense? Is the correct solution to have Pango ignore resolution on MacOS or to always set GdkScreen resolution to 72? If the latter, what about the other functions that use scaling information and how to communicate to applications that they need to use larger icons and such?

Regards,
John Ralls



_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Loading...