New Wayland Protocol Proposed For Fractional Scaling

[RahulSundaram]

Again, pretending to miss the point. We're not talking about rewriting Wayland, we're talking about a relatively small addition that was highly requested.

I am not pretending anything. Since you originally talked about 10 years of Wayland, I had the impression that you are talking about all of Wayland, not just a specific feature. You can't implement a specific feature directly without implementing all the dependencies that it needs to be actually usable for users, so you have to consider the full scope and it is certainly not a small addition at that point. You also said it is already implemented in X but you should be aware that X implementation is hacky. All it does is implement integer scaling and then zooming. You can already do that with GNOME Mutter too but a proper implementation does not exist in X or Wayland.

[billyswong]

I'm referring to this definitions

https://www.phoronix.com/forums/foru...80#post1317880

Okay I get the terminology now. I would rather call them compositor-based scaling and application-based scaling. The third mode in Windows that Ladis mentioned could be called toolkit-based scaling. For that mode, the GUI toolkit scales stuff as best as it can while the application writer does no accommodation for it, resulting in a frankenstein of sharp and proper sized + sharp but tiny / scaled but blurry. Yes, what Windows originally did in Win 9x / XP era does not work like that, but at that time PCs were all single-threaded. Asking all programs to pour their drawing call into the same queue didn't seem problematic. Now we are stuck with, what sinepgib said, the "code duplication" and "bloat".

[Ladis]

Okay I get the terminology now. I would rather call them compositor-based scaling and application-based scaling. The third mode in Windows that Ladis mentioned could be called toolkit-based scaling. For that mode, the GUI toolkit scales stuff as best as it can while the application writer does no accommodation for it, resulting in a frankenstein of sharp and proper sized + sharp but tiny / scaled but blurry. Yes, what Windows originally did in Win 9x / XP era does not work like that, but at that time PCs were all single-threaded. Asking all programs to pour their drawing call into the same queue didn't seem problematic. Now we are stuck with, what sinepgib said, the "code duplication" and "bloat".

Yes, the third mode in Windows works only when app draws via the old-school GDI (not GDI+) commands. That covers classic GUI programs and classic .NET programs. The GDI library translates the commands itself. The good thing, nothing is tiny. It's just texts are sharper (Microsoft had to tune the font thickness in the later updates) and bitmaps are not tiny, instead proper size (but blurred).

However! This mode is only a bonus. The main advantage of Windows is, the user is the king. Not some developers in the "mom's basement" You as a user can override what the mode would be chosen by Windows or the application. E.g. Some apps wrongly report they support HighDPI, but many parts in them are broken. Or some apps support at least 125% DPI (which comes from Windows 3.1 from 1993, so you may find it even in 20 years old apps) and since that's the most common DPI on PC notebooks and many desktops, why to have it blurry (those old apps don't have a manifest included saying they support it, also they don't support higher DPI than 125%, so they wouldn't tell truth anyway).

Fun fact - even macOS takes its users more serious than Linux. There you also can override what mode would be used per app. If the app reports it supports HighDPI and it's bad, you can force to open it in LowDPI:
https://www.idownloadblog.com/2016/0...-display-macs/

As i know, Fedora uses the trick to tell the real DPI to Chrome running in XWayland, so it's sharp. Because it's not true X11 doesn't support HighDPI - we enjoyed it long before Wayland got its first usable version after a decade of development. The problem is - I, as a user, can't turn on this feature for other X11 apps, which I know works well (some may need restarting, but that's not a problem for users, who don't have multimonitor multi-DPI setup).

PS: There's a difference between HighDPI and MultiDPI. MultiDPI means, app responds when its window is moved to a display with different DPI. In Windows, such old apps supporting HighDPI, but not MultiDPI, are rendered in the primary display's DPI and then scales like a bitmap on other displays. Still sharper that using 100% DPI.

[oiaohm]

Okay I get the terminology now. I would rather call them compositor-based scaling and application-based scaling. The third mode in Windows that Ladis mentioned could be called toolkit-based scaling. For that mode, the GUI toolkit scales stuff as best as it can while the application writer does no accommodation for it, resulting in a frankenstein of sharp and proper sized + sharp but tiny / scaled but blurry. Yes, what Windows originally did in Win 9x / XP era does not work like that, but at that time PCs were all single-threaded. Asking all programs to pour their drawing call into the same queue didn't seem problematic. Now we are stuck with, what sinepgib said, the "code duplication" and "bloat".

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1317853-new-wayland-protocol-proposed-for-fractional-scaling?p=1318028#post1318028

I do cover the different application and compositor scaling here. Toolkit scaling is a subset of Application based scaling. Toolkit scaling fails in some applications because developer added something not in the Toolkit that does have proper control of this happens under windows as well. So you get sharp and proper sized and scaled by some means and the odd what the heck with Toolkit scaled.

What the heck can be stuff that should not be stacked on top of each other being stacked on top of each other due to display location mix ups and so on. This is way Mac OS has force low DPI. Reality is Mac OS heavily uses toolkit scaling and it does not always work.

The hard reality with application output scaling its not a 1 size fits all problem.

[Ladis]

https://www.phoronix.com/forums/foru...28#post1318028

I do cover the different application and compositor scaling here. Toolkit scaling is a subset of Application based scaling. Toolkit scaling fails in some applications because developer added something not in the Toolkit that does have proper control of this happens under windows as well. So you get sharp and proper sized and scaled by some means and the odd what the heck with Toolkit scaled.

What the heck can be stuff that should not be stacked on top of each other being stacked on top of each other due to display location mix ups and so on. This is way Mac OS has force low DPI. Reality is Mac OS heavily uses toolkit scaling and it does not always work.

The hard reality with application output scaling its not a 1 size fits all problem.

Yes, technically, scaling in Windows and macOS is a toolkit scaling, because you don't draw windows directly (I don't count apps drawing via DirectX or OpenGL, e.g. games). However, if Linux didn't have so many toolkits and their versions, and older versions not maintained about new features, they could have this way, too (it's not even possible nowadays to unify the theme gtk4/3/2/qt6/5/4*). Add in profiles from the distribution (like Fedora has for Chrome) and ability for the user to override it, like on Windows and macOS, and everybody would be happy. Not white-listed apps or overriden by the user will have the safest way of DPI 100% scaled as a bitmap (I hate the idea that if you can't make 100% perfect, then you shouldn't try at all).

*) I remember the golden times of Linux, when distibutions had unique looks (including having that theme for both gtk2 and qt3 - current versions at the time - and at least "system colors" for X11 apps drawing without any toolikt or some like Tcl/Tk), differing them visually from other distributions. Even Ubuntu doesn't have own theme anymore.

[Quackdoc]

Again, pretending to miss the point. We're not talking about rewriting Wayland, we're talking about a relatively small addition that was highly requested.

ah I understand what you were saying now, that's what i was saying I do by changing TTY and using MPV directly, currently on wayland when you have fractional scaling on pretty much all compositors take the approach of rendering at the next interger scale then downscaling (IE. 4k 150% scale (essentially 1440p) scales everything at 5k, then downscales to 4k) even for native 4k content. (though it is particularly bad when up-scaling 1080p content to 5k then downscaling from there)

the only way around that currently is to
A) DIsable scaling which is a hassle
B) Change compositors to one that isn't being scaled (simply start a second compositor like sway on a second TTY)
C) just use MPV directly with DRM backend (also possible by just changing TTY)

I elect for C usually as on intel devices it can also utilize HDR (I think some AMD devices can too?) when using DRM backend, (kodi too)

[arQon]

Hmmm.... a new protocol for fractional scaling.

How come they didn't think of this years ago?

Exactly so. SIGH...

This is Wayland in a nutshell: basic functionality that everyone knew was needed at least 20 years ago, which is somehow still missing after 10+ (15+ now?) years of development.

I haven't read the other five pages of comments yet, but I'll bet it's got the usual flood of "AKSHUALLY, wayland is just a protocol, so it missing features is fine" posts. Or blaming the compositors, or etc etc.

[oiaohm]

Yes, technically, scaling in Windows and macOS is a toolkit scaling, because you don't draw windows directly (I don't count apps drawing via DirectX or OpenGL, e.g. games). However, if Linux didn't have so many toolkits and their versions, and older versions not maintained about new features, they could have this way, too (it's not even possible nowadays to unify the theme gtk4/3/2/qt6/5/4*).

Sorry this arguement is bogus with scaling.

https://en.wikipedia.org/wiki/Qt_(software)#Applications_using_Qt

Like it or not Qt multi versions is on Window and MacOS as well. Reality here is even applications not running by Direct X or Opengl and are not games don't always use the OS provided toolkit under Windows or MacOS. This is were toolkit scaling start falling apart on all platforms. Please note applications using Qt on Windows can choose use to use freetype for all font rendering as in all text of the application without using the host provided font rendered.

This is only a single example. The reality here is Windows, MacOS and Linux all have many graphical toolkits to deal with when scaling. Yes on Windows, MacOS and Linux platforms there are about the same number of GUI toolkits in use. Having the OS provide a toolkit does not prevent graphical toolkit fragmentation.

There are unified standards for toolkits to get scaling information and colour/theme information from under MacOS and Windows.

Add in profiles from the distribution (like Fedora has for Chrome) and ability for the user to override it, like on Windows and macOS, and everybody would be happy. Not white-listed apps or overriden by the user will have the safest way of DPI 100% scaled as a bitmap (I hate the idea that if you can't make 100% perfect, then you shouldn't try at all).

Please note I am not saying people should not try at all. I am saying there is a time to admit that something does not have a single solution. In the case that something does not have a single solution you except it and provide the multi solution that covers all cases.

Like fractional scaling and interger scaling without blur and integer scaling with blur at the compositor each alone does not suite all but selectively being able using all 3 covers more uses cases than any of those three options alone.

Ladis the way you were thinking was if the OS provided a single toolkit that fixes the problem again here is you looking for a single solution fix for a problem that does not have a single solution fix at all even under windows or mac os. Yes toolkit fragmentation is a big reason why MacOS and Windows does not have a single solution fix from the OS provided toolkits.

*) I remember the golden times of Linux, when distibutions had unique looks (including having that theme for both gtk2 and qt3 - current versions at the time - and at least "system colors" for X11 apps drawing without any toolikt or some like Tcl/Tk), differing them visually from other distributions. Even Ubuntu doesn't have own theme anymore.

The X11 protocol never defined system colors. Please take off your rose colour glasses and look again and see that it was only working by a stack of hacks back then.

There has been a lack of proper formal solution for scaling and theming that covers the all use cases correctly.

[Ladis]

...

I never told Windows and Mac have only one toolkit. But they have one default, used e.g. by system apps and at least half software for that platform. Compare it to Linux, where not only we have GTK and Qt, but they are also separate about their major versions. E.g. you have to create separate themes for each gtk4, gtk3, gtk2, qt6, qt5, and qt4 (if I was counting the age of Window GDI and Mac Cocoa, I would have to add also gtk1 and qt2). That's why no distribution nowadays has a unique look - they all are forced to the predefined vanilla themes.

[oiaohm]

I never told Windows and Mac have only one toolkit.

Horrible part is you are kind of wrong still you did not get .

But they have one default, used e.g. by system apps and at least half software for that platform.

This is right for MacOS but in fact wrong for Windows.

https://en.wikipedia.org/wiki/Universal_Windows_Platform_apps

One of the most recent new toolkits on Windows is Metro. In fact the on windows not all the system applications use the same toolkit. In there are a lot cases on windows with the include software that to draw title bar is in fact done in different DLL file so different executable code so truly executable code split toolkits

Compare it to Linux, where not only we have GTK and Qt, but they are also separate about their major versions. E.g. you have to create separate themes for each gtk4, gtk3, gtk2, qt6, qt5, and qt4 (if I was counting the age of Window GDI and Mac Cocoa, I would have to add also gtk1 and qt2). That's why no distribution nowadays has a unique look - they all are forced to the predefined vanilla themes.

Lets say we take all toolkits off Linux and put them on Windows. All of them can be set to use the windows registry stored theme data. Lets say we put them all on Mac OS again they can use the common platform theme data. Question where is the Linux platform common theme data the reality it does not exist.

Exactly why are we creating per toolkit themes? All the graphical toolkits used on Linux are perfectly able to cope with using external theme data when not on Linux.

The theme data under Linux that people make themes with lot of ways should own to application developer not end user. Because when developing for window and mac os applications developers with GTK/QT.... normally still create a theme file with selective import of information from host global theme data.

Ladis I guess you never considered the case that you could change platforms yet keep the toolkits the same and basically make the problem disappear. Then did not consider what this was telling you.

You have and many others been incorrectly presuming Windows comes with 1 GUI toolkit that is not the reality this lead to the false arguement that since windows has one default toolkit this is solution. Reality windows comes out the box with many default GUI toolkits just the default GUI toolkit use the same registry entries for theme data. Microsoft makes new GUI toolkits a lot more often than most presume only most people don't notice it due to global theme data.

The problem is not the multi toolkit the problem is lack of global theme data standard for the multi toolkits to use.