5 ms·

Depends how you define "work". Since X11 apps can find out the display dpi and render accordingly, they do not communicate to compositor at which scale they re

Depends how you define "work". Since X11 apps can find out the display dpi and render accordingly, they do not communicate to compositor at which scale they really do render their contents. This gets even more interesting, once there are multiple scales (i.e. you have multiple displays, each at different scale). This leads to compromise, where xwayland assumes that all X11 clients render at 96 dpi and upscales them to the actual one. It is not pretty, bilinear would not be my choice of algorithm here, but the apps are at least correct size. There are patches floating around that modify this assumption, let X11 clients render at actual dpi, and if they don't, let have the user apps with tiny UI. So YMMV.

michaelmrose 4y ago
This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. However X does this it doesn't result in a blurry mess. Logically there is no particular reason it can't be done well on xwayland. To be charitable one would suppose that its just a low priority as fewer people have high dpi displays. If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. If you listen to these people talk the less charitable interpretation sounds entirely plausible.
- vetinari 4y ago
  > This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't. I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't. In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well. > To be charitable one would suppose that its just a low priority as fewer people have high dpi displays Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling. With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable. > If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. > If you listen to these people talk the less charitable interpretation sounds entirely plausible. AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere. But as they say, patches welcome.
  - michaelmrose 4y ago
    Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry. You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work. All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise. A tiny amount of effort by your distro could easily erase even that by simply doing it for you. >IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Then you can call them all luddites for caring more about working hardware than plumbing.
    - vetinari 4y ago
      > Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.

michaelmrose 4y ago

This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. However X does this it doesn't result in a blurry mess. Logically there is no particular reason it can't be done well on xwayland. To be charitable one would suppose that its just a low priority as fewer people have high dpi displays. If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. If you listen to these people talk the less charitable interpretation sounds entirely plausible.

vetinari 4y ago
> This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't. I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't. In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well. > To be charitable one would suppose that its just a low priority as fewer people have high dpi displays Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling. With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable. > If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. > If you listen to these people talk the less charitable interpretation sounds entirely plausible. AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere. But as they say, patches welcome.
- michaelmrose 4y ago
  Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry. You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work. All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise. A tiny amount of effort by your distro could easily erase even that by simply doing it for you. >IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Then you can call them all luddites for caring more about working hardware than plumbing.
  - vetinari 4y ago
    > Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.