[vetinari]

And we hit the typical problem with software evolution.

The apps would have to cooperate, and that would need rewrite. In many cases, re-architecturing them.

Who is going to do that? Nobody. We need to live with the legacy that we have. How resizing non-compliant applications works (and looks), see the experimental fractional support in Mutter.

[bayulxc5]

Most if not all Windows applications can be resized properly without being updated. Remember that it's the widget toolkit (Win32, GTK, Qt, etc) that is doing the resizing, not the application.

The app tells the toolkit to draw a button at 10,10 with a size of 100,20. The toolkit multiplies everything by 1.5 and then draws the button. The app doesn't need to know that this is happening at all. Of course this is not possible with some applications that do weird things, but for the 99% this works, and the 1% can just be resized by the compositor. That's exactly what Windows does.

[vetinari]

In the Linux world, you cannot rely on the widget toolkit doing the heavy lifting. The API is defined on the socket protocol level, not on the symbols of the library level, so you have to handle it there. The old xeyes or xfontsel, or other athena, motif, openlook, fltk or whatever forgotten apps, that conform to x11 protocol, must be handled too. The scaling at compositor level is the easy part, Wayland compositors have per-surface flag, how it is supposed to scale in the composition, they are aware also of the scaling needed by each display. The issue is, that the X11 clients - unlike Wayland clients - do not announce what they are capable of. As you noted, both Windows and macOS can fix this in the framework, where Linux cannot. macOS even took the shotgun approach and required a flag in the executable header for the scaling capability announcement part. Such approach is not passable in the Linux world.

But Windows is not a garden of roses either, I still see a fair share of blurry dialogs (until recently, even vscode installer/updater).