New Wayland Protocol Proposed For Fractional Scaling

[skerit]

How does Gnome's Mutter wayland display server currently handle fractional scaling? The hidden config you currently have to enable is called

scale-monitor-framebuffer

[IndioNuvemChuva]

so then it will be like X with 30 years less of papercuts.

"So, you see, guys, because X has sucked for so long that means we can't have nice things."
I genuinely don't see the point in bringing this up every time anyone so much as mentions a flaw or shortcoming in Wayland.

[Vistaus]

* Clicks Link
* CTRL+F
* GTK2
-- Phrase not found

Well, crap

I'm still hoping this'll lead to Steam not looking like...well, crap

GTK2 doesn't officially support HiDPI, however, you can use Oomox/Themix to create or install a HiDPI-like GTK 2 theme. And as for Steam: you can install a different skin with HiDPI support or enable the Steam Deck interface.

But I agree that Steam needs to come up with a better interface by default.

[bug77]

They started out with the core protocol and incrementally added extensions over time just like any other project would. This is a process that takes time because there are a lot of considerations to take into account and the ecosystem is underfunded. Users assumed they are against something when it wasn't implemented earlier. If you have any evidence of them fighting users, feel free to link to it.

Taking over 10 years for something that was available on X all this time isn't evidence enough?

[Quackdoc]

finally, this should let compositors stop doing the method of setting the resolution then downscaling. this means we can finally watch videos without upscaling then downscaling from there. or doing what I did, and changing to a different tty and either running mpv directly or using another compositor

[tornado99]

This was considered when integer staling was added to wayland protocol. At this stage they have still left out how fine grained it should be.



There is a difference between DPI scaling and this form fractional scaling. IOS does not in fact have this form of fractional scaling it only has what is the old DPI scaling. This is where you give the application 1 DPI value for the screen then application renders for that.

Wayland include integer compositor can ask application for window to be rendered at a higher 2x 3x.... by application if application refuses the compositor can upscale to this without introducing artefacts. People with eye disorders/diseases this kind is reasonable.

https://www.ghacks.net/2020/09/18/how-to-fix-blurry-text-in-programs-on-windows-10/

Something to remember even Microsoft Windows does not have fractional scaling perfectly squared away. Yes will be cases where you will not want fractional scaling due to application coming blurred.

Yes sometimes with some applications having the window split between two screens in fact not at the same ratio so monitors next to each top and bottom of the window don't in fact line up will be the correct answer. Yes this is what happens when you enabled dpi locking under windows.

The reality we need fractional scaling, integer scaling and DPI locked scaling yes this is to deal with all the different applications users could want to run and their quirks and the users vision issues..

DPI locked scaling this one where the DPI the application is set to one value and the application is rendered to monitor without care in the world what the DPI of the monitor is. So application could render too big or too small on the monitor as you cease to care that a inch/cm is not aligned to what application thinks a inch/cm on screen is so giving up the WYSIWYG(What You See Is What You Get) logic of scaling.. This case user will set either a DPI of one of the monitors or a mid value they class as useful.

This is also part of the problem people keep on asking for non blurry scaling and also asking for fractional scaling. Fractional scaling always has a level of you will get blur from time to time and overhead.

Yes integer scaling has overhead with buffers and the like. This is where DPI locked scaling comes in.

So DPI Locked scaling, fractional scaling and integer scaling all have there cases of being totally cursed and all have there cases where they are the best solution to the problem over the other two. This is why this debate has been stuffed for over 20 years. Yes arguments start before Wayland exists. Biggest problem has been the solution must be perfect in all cases and reality that does not exist with fractional scaling, integer scaling or DPI locked scaling alone. Please note perfect in all cases without having the user choose anything is another thing that has been demanded this is basically not possible.

Hard part is admitting the reality that something is impossible so half measures are required that will require to provide users with settings and guidance to set stuff up right.

The thing that bothers me the most is that Wayland cannot render 2x scaling sharp for xwayland apps. This shouldn't be difficult as there are no fractions, it is integer scaling. On my 4K monitor with 200% scaling, every Wayland app is sharp, every XWayland app is blurry.

[RahulSundaram]

Taking over 10 years for something that was available on X all this time isn't evidence enough?

No. Bcachefs is taking over 7 years to do what several other filesystems can already do now for example even though the developer is building off an existing project - bcache. Pipewire has been under development for over 7 years as well even though many people think it got mature quickly because it was just made the default in Fedora after a very long time of more quieter development. It is just evidence that complicated projects take time. It is not like there is a lot of commercial desktop linux usage funding it. No reason to automatically assume malice here.

[oiaohm]

The thing that bothers me the most is that Wayland cannot render 2x scaling sharp for xwayland apps. This shouldn't be difficult as there are no fractions, it is integer scaling. On my 4K monitor with 200% scaling, every Wayland app is sharp, every XWayland app is blurry.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1787

Problem this is another area where there is no correct answer. People complain that straight integer scaling result in stuff being too jagged so then someone implements a blur to smooth that out then other people complain that this is now blurry for their usage case. Gamescope and sway and most other wlroot based compositors contains straight non blur integer scaling as default option so its not Xwayland causing this problem is choice of Wayland compositor yes gnome having a blur there is because people complained.

Some of these setting really do need to be per application for what kind of scaling to use. Yes there are two integer scale options when application does not scale themselves. Yes Xwayland the wayland compositor in most cases is doing the scaling so has choice between the two options.
1) Integer scaling without a blur function to smooth stuff out so to some users appears horrible jagged and hard to read.
2) Integer scaling with blur function removes the jagged and makes it hard to read for a different group of users.

Reality here we just need to give the user choice of choose do you wanted jagged or do you want blurred on a per application base if compositor has to scale itself. We also do need to teach users that this is a choice and there is really no automatic solution that works all the time for all users.

DPI Locked scaling, fractional scaling and integer scaling what I mentioned in the past post is what you request of application programs to make for the compositor.

This blur or not to blur this is what you get into when you come to the compositor scaling.

Of course DPI locked scale method cannot be performed by compositor and it application side pure thing.

Hard reality here compositor performing fractional scaling will always be performing some form of blur function that could make the out put too blurry for some users. Yes compositor performing integer scaling has choice between using a blur function and not using a blur function.

The reality is there are 7 different scaling here.
1) application DPI Locked scaling
2) application fractional scaling
3) application integer scaling where application chooses if it use some form of smoothing/blur/subpixel rendering or not this can be quite smart like fonts shape smoothed correctly.
4) application doing no scaling
5) Compositor integer scaling without blur this can make text and images jagged/pixelised
6) Compositor integer scaling with blur fixes the pixelized problem but make output blurry in some cases..
7) Compositor fractional scaling has all the same issues as Compositor integer scaling with blur because blur function is a required feature to perform this.
8) Compositor doing no scaling

Yes we need two controls here remember the compositor scaler can be stacked on top of application scaling. So you might have a application in DPI locked scaling then perform a compositor integer scaling without blur and so on so basically 16 different combinations here.

The reality here suxs right. Compositor developers don't want to have to implement there scale function 2-3 times or more this is just resisting reality. The reality to get correct for user outcome the compositor scaler need to be done 3 times with some way to define maybe in the .desktop files what one should be used for the application. Some ways there should be a shared library for all Wayland compositors to use that is the 3 required output scaling solutions that Compositor need to be able to perform.

tornado99 this is most likely not the answer you wanted.

[tornado99]

oiaohm , thanks for the reply but I am not referring to scaling of images or game graphics. I'm talking about text, and the vector elements of a desktop application. These will not look jagged at all when rendered at 2x scaling on a 4K monitor, in fact they will be perfectly sharp as you are using 4 pixels for every 1 pixel on a 1080p display. There are no fractions of pixels involved.

[Ladis]

In ideal world, the same (i.e. physical size of elements) must also be by default for, e.g., 24" 1920x1080 and 24" 2560x1440, unless a user doesn't care about their eyes, and wants to become blind fast. It is strange that fractional scaling isn't the very first priority for those outreach programs, it's like they don't care about people with eye disorders/diseases or bad sight.

Before "Retina" displays in Macs (DPI 200%), MacOS worked that way you had DPI "100%" no matter of pixel density. E.g. Air had 1440x900 while the same 13" screen size in the base and Pro 13" MacBook had 1280x800. Similarly there was a special display in 15" MacBooks with bigger resolution and smaller pixels (the screen border was aluminium/light gray instead of the usual black one). And when Apple gave High DPI, it was first only 100% (2x2 pixels) and 200% (native resolution). It took years to give fractional scaling, and they do it without the application of knowing that, so no more work from app developers (render in 200% and downscale). Fun fact, it doesn't offer the 125% scale (the most common in PC notebooks /e.g. laptop with 15" FullHD/ and desktop displays /e.g. 2.5K 24"/ nowadays). It offers only 150 and 175%. There's a trick how to work around it, by creating a virtual monitor, but that adds to the lag.

* Clicks Link
* CTRL+F
* GTK2
-- Phrase not found

Well, crap

I'm still hoping this'll lead to Steam not looking like...well, crap

I remember Ubuntu with the Unity desktop environment had the ability to fractional scale gtk2 and qt4 apps. It worked simply - when you moved the window to another display, it sent the DPI change command. You can try it even today - change DPI in the desktop settings and see what apps rework their windows immediatelly. Those all worked fine.