On Thu, Apr 27, 2017 at 3:58 PM, Emmanuele Bassi <eba...@gmail.com> 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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to