They aren't forced to draw at 2x and be scaled down. They only need to do that if you have enabled fractional scaling. If you really want to avoid the overdraw associated with that, just don't use any scaling on your primary display and then turn the font size in your client up. Anything else that passes the fractional scale onto the client is going to have issues. The reason you pass the buffer scale in wayland is because you explicitly want the compositor to scale your buffer and you want it to do it correctly. If you don't want that, don't bother with messing with fractional scaling.
>you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties
Again, this comes back to the issue where now you need to deal with rounding in the client. Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer. And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)
> They aren't forced to draw at 2x and be scaled down. They only need to do that if you have enabled fractional scaling.
Fractional scaling is exactly what we're talking about. At 1x/2x everything works.
> If you really want to avoid the overdraw associated with that, just don't use any scaling on your primary display and then turn the font size in your client up.
That's what I do but doesn't work with mixed-DPI. The fact that it works and improves things just shows how this could be done better.
> The reason you pass the buffer scale in wayland is because you explicitly want the compositor to scale your buffer and you want it to do it correctly. If you don't want that, don't bother with messing with fractional scaling.
That's circular. You're arguing that the way things are done is an argument for things to continue to be done like that.
> Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer.
Both Firefox and Chrome have their whole UI scalable at arbitrary values and have for many years. See layout.css.devPixelsPerPx in Firefox for example. There's nothing special about the window where the Webpage/PDF/3D gets rendered versus the UI. Vector UIs that can scale arbitrarily not only exist they're widely used. And the worst case is still "if you don't know any better do 2x and scale down yourself client".
> And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)
You can't disable fractional scaling on a per-program basis, it wouldn't work at all, and it would still be broken in a mixed DPI setting. I want the Browser/PDF/Image/3D windows on my 1440p screen to have different scaling from my 4K screen and for them to switch scaling automatically, just like they resize automatically, when I switch them between screens. That's currently not possible because there's no support for it in Wayland.
>Fractional scaling is exactly what we're talking about. ... That's circular. You're arguing that the way things are done is an argument for things to continue to be done like that.
Actually no, what you are describing is ideally having no scaling at all in the compositor on any particular monitor. (Unless of course a window is stretched between them) I'm not arguing for things to be done any way, I'm saying don't misuse a feature that was designed to do something else than what you're asking for.
For a vector UI that is supposed to be pixel-aligned, you can't render that at a non-integer scale without the same blurriness that you would get with doing the scaling in the compositor. That's different from rendering print content that has no relation to pixels.
> For a vector UI that is supposed to be pixel-aligned, you can't render that at a non-integer scale without the same blurriness that you would get with doing the scaling in the compositor. That's different from rendering print content that has no relation to pixels.
That's one case where the downside is the same, not even worse, and the cases where that's not the case are broken. Wayland pushes a lot of things to the client, so it's surprising that the client can't make this decision when at worst the result has the same problem. And there are a lot of clients that could take advantage of this today. The browsers we are using to have this discussion are made needlessly blurry because of this. They have the whole stack ready for fractional scaling themselves and are forced to 2x and scale down by the compositor.
>you have a 150x150 window on which to display content at 1.33x scale, just give me back a buffer with those properties
Again, this comes back to the issue where now you need to deal with rounding in the client. Only the simplest of browsers, image viewers, 3D renderers, PDF viewers that have no UI chrome could get away with just passing on a fractionally scaled buffer. And for those, you can do what I described above, disable fractional scaling and do your scaling in the client, you don't need any special support in the compositor. I believe in most applications you can press Ctrl-Plus and Ctrl-Minus :)