Re: Wayland and fractional scaling

>
> No, it doesn't. Fractional scale factors are rounded up. In order to
> support scale factors such as 125% properly, we need changes in upstream
> protocols. As far as I know, no one has really started working on it.
>


This is sad. It seems it hasn't been discussed a lot. This is one mention
of the subject I found (
https://wayland-devel.freedesktop.narkive.com/Ew9ti0jg/patch-protocol-add-buffer-scale-to-wl-surface-and-wl-output
):

> I'm more and more likeing the way OSX solves this, i.e. only allow and
expose integer scaling factors in the APIs, but then do fractional
downscaling in the compositor (i.e. say the output is 1920x1200 in
global coords with a scaling factor of two, but actually render this by
scaling the user-supplied buffer by 0.75). It keeps the implementation
and APIs very simple, it does the right thing for the "nice" case of 2x
scaling and it allows the fractional scaling.


Most non-Apple average laptop screens these days are FHD, not retina, with
natural scale factors of 125-150% though, thus a raster 1.7 to 2.5 times
larger will be required and the pixel density < 200 dpi may not be enough
to hide the blurriness introduced by downscaling. I would even argue that
the output of a pure Qt Plasma Xorg session in my FHD laptop looks crisper
that the output of my MBP with its thick fonts.

For the user all this means increased cpu/gpu usage, decreased battery
life, degraded output quality (specially, font rendering). It's
somehow appalling
that the alternative of providing fractional scaling at the protocol level
was barely considered. Maybe it was the time the discussion took place,
maybe it was the GTK centeredness, I don't know. But nowadays this decision
imposes a heavy tax on Qt, browsers and other engines that can do better.

Could someone with more knowledge and experience than me open this
discussion again?a

Best regards
---
Carlos