4 ms·

With Xwayland. On hidpi display they will be upscaled and blurry, but at the right size and they will work in the first place. Even window grabbing will work,

With Xwayland. On hidpi display they will be upscaled and blurry, but at the right size and they will work in the first place. Even window grabbing will work, albeit only with other Xwayland clients.

AshamedCaptain 6y ago
Xwayland is the kludge I was talking about (and this article). No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs https://www.youtube.com/watch?v=BrK4c7iFJLs
- vetinari 6y ago
  X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless; it should get Xquartz treatment. The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything. For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").
  - AshamedCaptain 6y ago
    > The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. I Just make a new property, and make those DPI-aware clients set it! You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence). > For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.
    - vetinari 6y ago
      > Just make a new property, That's the easy part. > and make those DPI-aware clients set it! That's the difficult part. You are welcome to try, though! > You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does? > E.g. can Firefox already screen grab from Wayland these days? Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all. > Will Zoom ever do it? That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point. > And work with any Wayland display server other than Gnome's? That's a question you have to ask the authors of any Wayland display server other than Gnome's. > It is a mess, and has been so for a decade already. And that is why we get this article. It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.
      - AshamedCaptain 6y ago
        > That's the difficult part. You are welcome to try, though! I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution? What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.
        vetinari 6y ago
        > I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution? Because if it was just setting a new property in a toolkit, we would not have this discussion now. Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.

With Xwayland. On hidpi display they will be upscaled and blurry, but at the right size and they will work in the first place. Even window grabbing will work, albeit only with other Xwayland clients.

AshamedCaptain 6y ago

Xwayland is the kludge I was talking about (and this article). No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs https://www.youtube.com/watch?v=BrK4c7iFJLs

vetinari 6y ago
X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless; it should get Xquartz treatment. The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything. For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").
- AshamedCaptain 6y ago
  > The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. I Just make a new property, and make those DPI-aware clients set it! You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence). > For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.
  - vetinari 6y ago
    > Just make a new property, That's the easy part. > and make those DPI-aware clients set it! That's the difficult part. You are welcome to try, though! > You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does? > E.g. can Firefox already screen grab from Wayland these days? Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all. > Will Zoom ever do it? That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point. > And work with any Wayland display server other than Gnome's? That's a question you have to ask the authors of any Wayland display server other than Gnome's. > It is a mess, and has been so for a decade already. And that is why we get this article. It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.
    - AshamedCaptain 6y ago
      > That's the difficult part. You are welcome to try, though! I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution? What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.
      - vetinari 6y ago
        > I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution? Because if it was just setting a new property in a toolkit, we would not have this discussion now. Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.