6 ms·

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 com

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.
- cycloptic 6y ago
  The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer. >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. Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a box of 133.333333 x 133.333333 pixels? If you say "round in some direction" this is now a policy that must propagate to every bit in the stack that touches input and rendering. >It's no worse than the current solution for that screen and better for the one that matches. It actually is much worse for the one that doesn't match, because now you have lost the ability to do pixel-perfect scaling.
  - Dylan16807 6y ago
    You already have to propagate code all over to handle integer multiples, don't you? The email seems to be worried about things happening at the wayland level with fractions, but that's easily solved by rounding entire windows to the nearest pixel.
    - cycloptic 6y ago
      You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules. I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causing artifacts or error build-up is to have to compositor only do the rounding as the last step, which is the way it works now, and you have to use an integer scale for that. As you describe, this is the "easily solved" way, but it's only really easy because the compositor gets to handle it internally -- once you push that problem to clients it gets significantly harder.
      - pedrocr 6y ago
        Quite the opposite. Once you push the problem to the client a lot of them already know how to do it and by not doing two scaling steps you can make much better decisions. And you don't need coordinates as floating point at all. What you need to do is tell the app "you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties". Wayland can work at integer coordinates all the way. The app also draws at integer coordinates it just uses the scaling factor to know what to do. It can even just replicate the 2x and then scale down solution if it doesn't know how to do anything better but plenty of code does know how to do something better and much faster. Browsers, image viewers, 3D renderers, PDF viewers, are all natively able to scale arbitrarily and yet are forced by wayland to draw at 2x and be scaled down.
hollerith 6y ago
>To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3? You replace it with a 33px tall font. This is what Gnome 3.38 actually does in my experience: on the computer on which I am writing this, I have a scale factor of 1.50 set in the Displays pane of Gnome Settings. Google Chrome and vscode show up in the output of xlsclients, which I am told means that they are talking to XWayland (and there are web pages promising that in a few months those 2 apps will be adapted to talk directly to wayland), and those 2 apps are blurry whereas Gnome Terminal and Evince (my PDF reader) do not show up in the output of xlsclients and those 2 apps are not blurry, but their default text size and the size of their UI elements are consistent with everything being scaled by 1.5.
- vetinari 6y ago
  > You replace it with a 33px tall font. You cannot. You would need 33,333333333px font; you cannot ignore the fractional pixel errors, otherwise you will get odd bugs.
  - hollerith 6y ago
    Yeah, well, what Gnome does is if you ask it for 150% scaling, then it actually gives you 147% scaling or 152% scaling to make the number come out even.
    - vetinari 6y ago
      Don't know about how Gnome does that[1], but Apple certainly does that, and it allows them to limit compounding of the pixel errors to a group of 8 or 9 pixels. Each new pixel group starts without any compounded error. [1] Last time I checked, they didn't scale entire framebuffer as Apple does it, with output scaler. It looked like they were scaling surfaces individually with GPU and then composed the scaled surfaces into framebuffer with the same dimensions as the display resolution.

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.

cycloptic 6y ago
The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer. >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. Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a box of 133.333333 x 133.333333 pixels? If you say "round in some direction" this is now a policy that must propagate to every bit in the stack that touches input and rendering. >It's no worse than the current solution for that screen and better for the one that matches. It actually is much worse for the one that doesn't match, because now you have lost the ability to do pixel-perfect scaling.
- Dylan16807 6y ago
  You already have to propagate code all over to handle integer multiples, don't you? The email seems to be worried about things happening at the wayland level with fractions, but that's easily solved by rounding entire windows to the nearest pixel.
  - cycloptic 6y ago
    You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules. I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causing artifacts or error build-up is to have to compositor only do the rounding as the last step, which is the way it works now, and you have to use an integer scale for that. As you describe, this is the "easily solved" way, but it's only really easy because the compositor gets to handle it internally -- once you push that problem to clients it gets significantly harder.
    - pedrocr 6y ago
      Quite the opposite. Once you push the problem to the client a lot of them already know how to do it and by not doing two scaling steps you can make much better decisions. And you don't need coordinates as floating point at all. What you need to do is tell the app "you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties". Wayland can work at integer coordinates all the way. The app also draws at integer coordinates it just uses the scaling factor to know what to do. It can even just replicate the 2x and then scale down solution if it doesn't know how to do anything better but plenty of code does know how to do something better and much faster. Browsers, image viewers, 3D renderers, PDF viewers, are all natively able to scale arbitrarily and yet are forced by wayland to draw at 2x and be scaled down.

hollerith 6y ago

>To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3? You replace it with a 33px tall font. This is what Gnome 3.38 actually does in my experience: on the computer on which I am writing this, I have a scale factor of 1.50 set in the Displays pane of Gnome Settings. Google Chrome and vscode show up in the output of xlsclients, which I am told means that they are talking to XWayland (and there are web pages promising that in a few months those 2 apps will be adapted to talk directly to wayland), and those 2 apps are blurry whereas Gnome Terminal and Evince (my PDF reader) do not show up in the output of xlsclients and those 2 apps are not blurry, but their default text size and the size of their UI elements are consistent with everything being scaled by 1.5.

vetinari 6y ago
> You replace it with a 33px tall font. You cannot. You would need 33,333333333px font; you cannot ignore the fractional pixel errors, otherwise you will get odd bugs.
- hollerith 6y ago
  Yeah, well, what Gnome does is if you ask it for 150% scaling, then it actually gives you 147% scaling or 152% scaling to make the number come out even.
  - vetinari 6y ago
    Don't know about how Gnome does that[1], but Apple certainly does that, and it allows them to limit compounding of the pixel errors to a group of 8 or 9 pixels. Each new pixel group starts without any compounded error. [1] Last time I checked, they didn't scale entire framebuffer as Apple does it, with output scaler. It looked like they were scaling surfaces individually with GPU and then composed the scaled surfaces into framebuffer with the same dimensions as the display resolution.