20 ms·

Wayland Protocol Finally Ready for Fractional Scaling

122 points by edward 4y ago

zmk5 4y ago
I wonder if this merge will improve the odd fractional scaling issues I've been having with my framework laptop. Blurry text and windows for electron apps really sours the experience of using the wayland with the laptops resolution.
- archseer 4y ago
  That's probably because a lot of electron apps still run via Xwayland and you need to opt into ozone (chromium Wayland implementation)
- dottedmag 4y ago
  This merge is not going to improve anything by itself, in the same vein as update to HTTP protocol is not going to improve any existing HTTP servers and clients.
  - Conan_Kudo 4y ago
    Protocol merges require compositor implementations to be ready ahead of merge.
    - dottedmag 4y ago
      They require two implementations. It's not going to help if these implementations are in the compositors nobody cares.
      - Conan_Kudo 4y ago
        In practice, at least one of them is Kwin or Mutter and the other is wlroots. So usually there's pretty decent coverage.
Aardwolf 4y ago
I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unnecessary mouse/keyboard to monitor delay -4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games -choosing to have vsync enabled or disabled in games -EDIT: I should another important one for me: xclip, read from and write to the clipboard in the command line How's the current situation of Wayland for these? Thanks!
- edent 4y ago
  I use Wayland and it has screenshot and screen recording tools. I don't notice any delay on keyboard or mouse entry across multiple monitors. Can't answer the rest.
  - maskros 4y ago
    He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay. You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subsystems like Wayland. Monitors are also often adding a frame or two delay to bump up their pixel "response times" and reduce ghosting by looking at future frames. I swear, using Wayland or MacOS or Windows 10 on the fastest hardware today still feels slower and laggier than 10 year old hardware running plain X11 or Windows 7 (with the compositor turned off). Given the choice between tearing and input lag, I'll take tearing any day.
    - cycomanic 4y ago
      It seems your subjective feeling is not reflected in measurements. At least for kwin wayland is as fast as uncomposited x11 https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...
Jonnax 4y ago
I think it's been 10 years since that Canonical Mir project that created a lot of drama. I remember Intel removing their code from their driver saying they won't support them as Wayland was the future, for example. And it finally gets fractional scaling now? How is colour management on Wayland? Is there HDR support?
- mort96 4y ago
  There has been "fractional scaling" support in the way macOS does it forever: if you wanna scale at 1.8x, let the application draw at 2x, then make the compositor downscale everything. So it's not like it hasn't been possible before, it's just more efficient now I suppose?
bluedino 4y ago
I was going to say something about it being 10 years now since Apple made high DPI screens mainstream. Windows still doesn't have it working 100% yet.
- grepfru_it 4y ago
  Hmm maybe I'm missing something but I have not had any scaling problems in Windows. Maybe an argument could be made that adjusting DPI is as easy as MacOS as of Win 11 (maybe Win 10 too but I didn't use Windows too much then), but I've never had a problem increasing scaling on any of my 4k screens
  - Firmwarrior 4y ago
    Windows has a lot of trouble when you have two monitors with different scaling amounts You drag an app between them and it goes apeshit, very annoying Otherwise it seems to work for me
  - vetinari 4y ago
    It is easy to find windows app, that is either blurry (basically almost all installers), or is confused by hidpi (take any qt app and you have 1:1 chance it will get it wrong, like this: https://imgur.com/a/Ad0ZkmX https://imgur.com/a/Ad0ZkmX).
- chrismorgan 4y ago
  On the specific topic here, fractional scaling, macOS gets it disastrously wrong, only supporting downscaling, which means that it’s impossible to get pixel-perfect output on fractional scales, which are the norm on most of their devices. I seriously can’t comprehend how they ended up going that way, given that they were the ones in a position to force developers to get things right, far more than Windows, but no, they just didn’t even try. On the contrary, Windows has worked with fractional scaling from the start of its high-DPI story, and although it did take a while to get it right in all circumstances (I think the last pieces came in 2017, with DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 and also incidentally GDI scaling to automatically improve most older, DPI-unaware apps), it’s been robust since on all but a few badly-made apps that claim DPI-awareness but actually lack it (and you can forcibly change how they behave if necessary).
Ericson2314 4y ago
I once tried bringing this up in the discussion, but I believe this protocol still works with some sort of "logic pixels" abstraction. And there is concern about rounding. If rounding / scaling artifacts are avoidable, this is fine. On the other hand if this stuff occurs in practice like with macOS (at least at one point, with the 2x render and downscale), this is totally fucked. Wayland is much more low level than, say, CSS. So I see zero problem if the scaling factor can instead be a black box which applications are familiar to treat however they like. This is how "*.dpi: 120" in a .Xresources file works, for example. Not all applications might be able to support fractional scaling, but those that do can do it perfectly without any risk of scaling artifacts. This was repeatedly rejected for reasons that I don't understand.
robinsonb5 4y ago
Is this something which applies at a constant scale factor across the entire session, or can this theoretically be applied on a per-application basis? Is it flexible enough to allow "zooming in" on a running application?
nyanpasu64 4y ago
As I've pointed out in the MR, this only allows compositors to communicate to windows a scale factor (how many framebuffer pixels to send for each logical pixel of window size), but does not switch window sizes and subsurface positions/sizes from integer logical pixels to fixed-point logical pixels (rounded to integer physical pixels) or integer physical pixels. So Wayland is absolutely not ready for pixel-precise window resizing and positioning in the presence of fractional scaling.
oxplot 4y ago
Little confused - I’ve been using fractional scaling on Wayland for 6 months now!
trytry45435 4y ago
How on Earth nobody thougt about making Wayland pluggeable, so somebody could perfect the art of screenshoting, other would perfect drawing windows, other capturing video, then this plugins would have been re-used by everybody out there. It was a good idea, but the implementation clearly isn't working. My bet: Wayland will be the Windows Vista or the OS/2 of Linux.

122 points by edward 4y ago

zmk5 4y ago

I wonder if this merge will improve the odd fractional scaling issues I've been having with my framework laptop. Blurry text and windows for electron apps really sours the experience of using the wayland with the laptops resolution.

archseer 4y ago
That's probably because a lot of electron apps still run via Xwayland and you need to opt into ozone (chromium Wayland implementation)
dottedmag 4y ago
This merge is not going to improve anything by itself, in the same vein as update to HTTP protocol is not going to improve any existing HTTP servers and clients.
- Conan_Kudo 4y ago
  Protocol merges require compositor implementations to be ready ahead of merge.
  - dottedmag 4y ago
    They require two implementations. It's not going to help if these implementations are in the compositors nobody cares.
    - Conan_Kudo 4y ago
      In practice, at least one of them is Kwin or Mutter and the other is wlroots. So usually there's pretty decent coverage.

Aardwolf 4y ago

I still use X11, where and rely on the following features (amongst others): -taking screenshots -auto keyboard/mouse scripting with xdotool -not have unnecessary mouse/keyboard to monitor delay -4K fullscreen, windowed fullscreen and windowed gaming with nvidia drivers, for native and steam proton games -choosing to have vsync enabled or disabled in games -EDIT: I should another important one for me: xclip, read from and write to the clipboard in the command line How's the current situation of Wayland for these? Thanks!

edent 4y ago
I use Wayland and it has screenshot and screen recording tools. I don't notice any delay on keyboard or mouse entry across multiple monitors. Can't answer the rest.
- maskros 4y ago
  He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay. You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subsystems like Wayland. Monitors are also often adding a frame or two delay to bump up their pixel "response times" and reduce ghosting by looking at future frames. I swear, using Wayland or MacOS or Windows 10 on the fastest hardware today still feels slower and laggier than 10 year old hardware running plain X11 or Windows 7 (with the compositor turned off). Given the choice between tearing and input lag, I'll take tearing any day.
  - cycomanic 4y ago
    It seems your subjective feeling is not reflected in measurements. At least for kwin wayland is as fast as uncomposited x11 https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...

Jonnax 4y ago

I think it's been 10 years since that Canonical Mir project that created a lot of drama. I remember Intel removing their code from their driver saying they won't support them as Wayland was the future, for example. And it finally gets fractional scaling now? How is colour management on Wayland? Is there HDR support?

mort96 4y ago
There has been "fractional scaling" support in the way macOS does it forever: if you wanna scale at 1.8x, let the application draw at 2x, then make the compositor downscale everything. So it's not like it hasn't been possible before, it's just more efficient now I suppose?

bluedino 4y ago

I was going to say something about it being 10 years now since Apple made high DPI screens mainstream. Windows still doesn't have it working 100% yet.

grepfru_it 4y ago
Hmm maybe I'm missing something but I have not had any scaling problems in Windows. Maybe an argument could be made that adjusting DPI is as easy as MacOS as of Win 11 (maybe Win 10 too but I didn't use Windows too much then), but I've never had a problem increasing scaling on any of my 4k screens
- Firmwarrior 4y ago
  Windows has a lot of trouble when you have two monitors with different scaling amounts You drag an app between them and it goes apeshit, very annoying Otherwise it seems to work for me
- vetinari 4y ago
  It is easy to find windows app, that is either blurry (basically almost all installers), or is confused by hidpi (take any qt app and you have 1:1 chance it will get it wrong, like this: https://imgur.com/a/Ad0ZkmX https://imgur.com/a/Ad0ZkmX).
chrismorgan 4y ago
On the specific topic here, fractional scaling, macOS gets it disastrously wrong, only supporting downscaling, which means that it’s impossible to get pixel-perfect output on fractional scales, which are the norm on most of their devices. I seriously can’t comprehend how they ended up going that way, given that they were the ones in a position to force developers to get things right, far more than Windows, but no, they just didn’t even try. On the contrary, Windows has worked with fractional scaling from the start of its high-DPI story, and although it did take a while to get it right in all circumstances (I think the last pieces came in 2017, with DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 and also incidentally GDI scaling to automatically improve most older, DPI-unaware apps), it’s been robust since on all but a few badly-made apps that claim DPI-awareness but actually lack it (and you can forcibly change how they behave if necessary).

Ericson2314 4y ago

I once tried bringing this up in the discussion, but I believe this protocol still works with some sort of "logic pixels" abstraction. And there is concern about rounding. If rounding / scaling artifacts are avoidable, this is fine. On the other hand if this stuff occurs in practice like with macOS (at least at one point, with the 2x render and downscale), this is totally fucked. Wayland is much more low level than, say, CSS. So I see zero problem if the scaling factor can instead be a black box which applications are familiar to treat however they like. This is how "*.dpi: 120" in a .Xresources file works, for example. Not all applications might be able to support fractional scaling, but those that do can do it perfectly without any risk of scaling artifacts. This was repeatedly rejected for reasons that I don't understand.

robinsonb5 4y ago

Is this something which applies at a constant scale factor across the entire session, or can this theoretically be applied on a per-application basis? Is it flexible enough to allow "zooming in" on a running application?

nyanpasu64 4y ago

As I've pointed out in the MR, this only allows compositors to communicate to windows a scale factor (how many framebuffer pixels to send for each logical pixel of window size), but does not switch window sizes and subsurface positions/sizes from integer logical pixels to fixed-point logical pixels (rounded to integer physical pixels) or integer physical pixels. So Wayland is absolutely not ready for pixel-precise window resizing and positioning in the presence of fractional scaling.

oxplot 4y ago

Little confused - I’ve been using fractional scaling on Wayland for 6 months now!

trytry45435 4y ago

How on Earth nobody thougt about making Wayland pluggeable, so somebody could perfect the art of screenshoting, other would perfect drawing windows, other capturing video, then this plugins would have been re-used by everybody out there. It was a good idea, but the implementation clearly isn't working. My bet: Wayland will be the Windows Vista or the OS/2 of Linux.