6 ms·

No, it's not, see my comment [1]. Wayland just punts on the issue by removing the compositor from any decision involving scaling. The "Wayland Way" is for the

No, it's not, see my comment [1]. Wayland just punts on the issue by removing the compositor from any decision involving scaling. The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits, and software (cough cough chromium) that is so complicated that it cannot use a toolkit. Some compositors like sway will let you do in-compositor scaling, but this is admittedly a kludge: it produces blurry scaled-up output instead of rendering at the right resolution in the first place. The sway authors acknowledge this; the feature is only there as a "better than nothing" workaround. [1] https://news.ycombinator.com/item?id=25973875 https://news.ycombinator.com/item?id=25973875

badsectoracula 6y ago
> The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then send notifications to the applications whenever the window changes monitor to alter their scale levels (this would also allow for custom per-window scale level that is applied on top of the per-monitor scale level in case someone wants to scale up/down a specific window - e.g. scaling up some notepad-like editor for a screencast). This does require each client (and toolkit) to support arbitrary scaling... and window managers to agree on such a message, though i do remember an email about this topic being posted on Xorg mailing list some time ago. AFAIK Qt should already provide the necessary functionality for this.
- vetinari 6y ago
  > FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.
  - badsectoracula 6y ago
    Right now there isn't any protocol for doing what i described, however this information could easily be added. EWM (or something like it) needs to be extended for scaling support. Applications could do the scaling themselves as they detect their toplevel windows be moved around, but i'm not aware of any application doing that and it'd be fighting the window manager so it isn't a good idea anyway. But the X server already provides all the necessary information and mechanism for implementing this, it is the clients that need to use it: the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager <-> compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor).
    - vetinari 6y ago
      > But the X server already provides all the necessary information and mechanism for implementing this, X server provides that at the display level, not at the screen level. If you do that at display level, you cannot move windows between displays, the application has to destroy and recreate them (out of all applications, only emacs can do that). If you want to use then per screen, how it is done today, then screens must have identical density. > the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager <-> compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor). Defining the protocol would be the easier part; persuading application authors to support it would be the hard part. They would ignore it for years to come. And that's for applications that are maintained or can be updated. So when you have to make changes, you might as well as change the protocol and adjust for achieving multiple additional objectives - which is exactly what Wayland did.
- cycloptic 6y ago
  What you are describing is not enough, the X server or the X compositor would still need to scale windows up/down if they don't support scaling or if you want to have fractional scaling. It's not something a old-style window manager can do -- There is just no real "Xorg way" on how to do this right now.
  - badsectoracula 6y ago
    This is only needed if a program doesn't support scaling itself and is something that a compositor can support. In addition there is a branch by Keith Packard for having server-side window scaling that could also be used for this and work independent of any window manager (though a compositor can also be made to work with any window manager - for example there are people using a compositor with Window Maker even though WM doesn't support composition).
cycloptic 6y ago
>Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits There is nothing that can be done about this from the view of the display server. The application and toolkits have to be updated to support high DPI.
pedrocr 6y ago
It would actually be great if Wayland would allow clients to handle HiDPI themselves but it doesn't which makes fractional scaling much worse than it needs to be. Wayland defines integer scaling only and then compositors scale 2x content down to 1.5x or whatever it is you want. This means that if you have an app that's capable of drawing at arbitrary scale you are still forced to draw at 2x and then be scaled down by the compositor. This is needlessly blurry and a performance penalty. Text can be drawn at arbitrary scale but is blurry because of this. Browsers can render at any resolution but have substantial performace penalties because of this (2x at common fractional scales). Anything that renders images also gets needless downscales because of this with both quality and performance penalties. It's a baffling decision to not do this client side and hopefully will be fixed with the evolution of the protocol.
- cycloptic 6y ago
  This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. A bit of background here: https://lists.freedesktop.org/archives/wayland-devel/2013-May/009497.html https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors? And if you wanted to avoid any additional scaling artifacts or rounding errors, how tall would you make the output buffer, in pixels? What happens when you try to stretch this window across multiple screens?
  - pedrocr 6y ago
    > This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. From your link: """ > While rendering at rational factor can't be of better quality, it can > however be done at a much higher quality than downscaling, faster and with > less memory usage. Perhaps, but that benefit diminishes compared to the cons. """ Being blurry and losing performance was deemed acceptable for other benefits. Maybe I'm discounting those benefits but the penalties are very real. 2x performance penalties in performance sensitive code and blurry scalable content like fonts are real downsides. Looking further down the thread what I think would be the ideal solution is what is being proposed and doesn't get any response: https://lists.freedesktop.org/archives/wayland-devel/2013-May/009512.html https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... The current solution actually seems much more complex than this as the protocol needs to actually know about scaling instead of the scaling factor being just some metadata about how things should be and have been rendered and everything else would be within the client and compositor code. > How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors? Fonts are not sized in pixels for the most part. Modern fonts are resolution independent and the renderers try hard to fit it to however many pixels you have. By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly. > What happens when you try to stretch this window across multiple screens? For this case your render at the maximum of the two fractional scales and scale down in the lowest one. It's no worse than the current solution for that screen and better for the one that matches.

badsectoracula 6y ago

> The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then send notifications to the applications whenever the window changes monitor to alter their scale levels (this would also allow for custom per-window scale level that is applied on top of the per-monitor scale level in case someone wants to scale up/down a specific window - e.g. scaling up some notepad-like editor for a screencast). This does require each client (and toolkit) to support arbitrary scaling... and window managers to agree on such a message, though i do remember an email about this topic being posted on Xorg mailing list some time ago. AFAIK Qt should already provide the necessary functionality for this.

vetinari 6y ago
> FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.
- badsectoracula 6y ago
  Right now there isn't any protocol for doing what i described, however this information could easily be added. EWM (or something like it) needs to be extended for scaling support. Applications could do the scaling themselves as they detect their toplevel windows be moved around, but i'm not aware of any application doing that and it'd be fighting the window manager so it isn't a good idea anyway. But the X server already provides all the necessary information and mechanism for implementing this, it is the clients that need to use it: the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager <-> compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor).
  - vetinari 6y ago
    > But the X server already provides all the necessary information and mechanism for implementing this, X server provides that at the display level, not at the screen level. If you do that at display level, you cannot move windows between displays, the application has to destroy and recreate them (out of all applications, only emacs can do that). If you want to use then per screen, how it is done today, then screens must have identical density. > the window managers need to implement some way to inform toplevel windows that they need to change scale (e.g. via a custom message), applications need to inform the window manager and the compositor that they support such scaling messages (e.g. via a window attribute) and compositors need to be able to scale windows that do not support this scaling (this will probably need a special window manager <-> compositor protocol for compositors that are independent from the window manager while still allowing the window manager to handle scaling without having to also be a compositor). Defining the protocol would be the easier part; persuading application authors to support it would be the hard part. They would ignore it for years to come. And that's for applications that are maintained or can be updated. So when you have to make changes, you might as well as change the protocol and adjust for achieving multiple additional objectives - which is exactly what Wayland did.
cycloptic 6y ago
What you are describing is not enough, the X server or the X compositor would still need to scale windows up/down if they don't support scaling or if you want to have fractional scaling. It's not something a old-style window manager can do -- There is just no real "Xorg way" on how to do this right now.
- badsectoracula 6y ago
  This is only needed if a program doesn't support scaling itself and is something that a compositor can support. In addition there is a branch by Keith Packard for having server-side window scaling that could also be used for this and work independent of any window manager (though a compositor can also be made to work with any window manager - for example there are people using a compositor with Window Maker even though WM doesn't support composition).

cycloptic 6y ago

>Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits There is nothing that can be done about this from the view of the display server. The application and toolkits have to be updated to support high DPI.

pedrocr 6y ago

It would actually be great if Wayland would allow clients to handle HiDPI themselves but it doesn't which makes fractional scaling much worse than it needs to be. Wayland defines integer scaling only and then compositors scale 2x content down to 1.5x or whatever it is you want. This means that if you have an app that's capable of drawing at arbitrary scale you are still forced to draw at 2x and then be scaled down by the compositor. This is needlessly blurry and a performance penalty. Text can be drawn at arbitrary scale but is blurry because of this. Browsers can render at any resolution but have substantial performace penalties because of this (2x at common fractional scales). Anything that renders images also gets needless downscales because of this with both quality and performance penalties. It's a baffling decision to not do this client side and hopefully will be fixed with the evolution of the protocol.

cycloptic 6y ago
This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. A bit of background here: https://lists.freedesktop.org/archives/wayland-devel/2013-May/009497.html https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors? And if you wanted to avoid any additional scaling artifacts or rounding errors, how tall would you make the output buffer, in pixels? What happens when you try to stretch this window across multiple screens?
- pedrocr 6y ago
  > This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. From your link: """ > While rendering at rational factor can't be of better quality, it can > however be done at a much higher quality than downscaling, faster and with > less memory usage. Perhaps, but that benefit diminishes compared to the cons. """ Being blurry and losing performance was deemed acceptable for other benefits. Maybe I'm discounting those benefits but the penalties are very real. 2x performance penalties in performance sensitive code and blurry scalable content like fonts are real downsides. Looking further down the thread what I think would be the ideal solution is what is being proposed and doesn't get any response: https://lists.freedesktop.org/archives/wayland-devel/2013-May/009512.html https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... The current solution actually seems much more complex than this as the protocol needs to actually know about scaling instead of the scaling factor being just some metadata about how things should be and have been rendered and everything else would be within the client and compositor code. > How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors? Fonts are not sized in pixels for the most part. Modern fonts are resolution independent and the renderers try hard to fit it to however many pixels you have. By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly. > What happens when you try to stretch this window across multiple screens? For this case your render at the maximum of the two fractional scales and scale down in the lowest one. It's no worse than the current solution for that screen and better for the one that matches.