[md8z]

"still missing crucial features such as fractional and consistent scaling"

This has very little to do with Wayland and mostly has to do with the apps and the toolkits. I haven't really seen many Linux native apps that are able to function correctly at a non-integer scale. The rendering of these apps may have to be entirely changed and refactored to use floating point instead of integers. That a big thing to ask every app to do. The hard part is doing that, and then it's trivial to put a flag in Wayland (or XWayland) for an app to say that it supports it.

[nextaccountic]

Clipboard is consistently broken on Wayland. I don't use any XWayland application, it's all native Wayland. Sometimes when I copy things they don't paste, and I need to switch back to the original window for the copy to register. Or even copy again to be sure. This was never, ever a problem in more than 10 years using X11.

But, fractional scaling is working like a charm on Gnome + Wayland (after a gsettings command). Very crisp, despite people saying it doesn't work. On X11, even on KDE, I can't get fractional scaling this crisp. This is the only reason I'm using Wayland; all the rest sucks.

But, the problem is, GTK doesn't support fractional caling natively. Even GTK 4 supports only integer scaling. So for fractional scaling the compositor has to scale up, then down. This approach generally causes blurring (though I don't know why Gnome on Wayland here isn't blurred).

When I see screenshots of people with fractional scaling on Gnome, it appears very blurry. Comparing side by side, here it isn't. I don't know why and at this point I'm afraid of messing it with and ruining everything.

[md8z]

"Sometimes when I copy things they don't paste, and I need to switch back to the original window for the copy to register."

I have honestly never had that problem in years of using GNOME Wayland, but I experienced it many times with misbehaved X11 apps. Maybe you want to come up with a reproducible test case and then report it?

"Even GTK 4 supports only integer scaling. So for fractional scaling the compositor has to scale up, then down. This approach generally causes blurring (though I don't know why Gnome on Wayland here isn't blurred)."

That's what I mean, it has to be done in the toolkits first. The first step would be to add support for that to GTK which is unlikely to happen until at least GTK5. Then after the apps can start to support it, I think you're looking at at least a few years before there is a realistic chance of having that. Sorry to disappoint, it's just not an easy thing to have. And I don't think there is much incentive to support this from a hardware perspective either since most people that I see asking for this are using it as a workaround for oddly sized 4K monitors.

"This is the only reason I'm using Wayland; all the rest sucks."

I feel your frustration but I actually would not suggest using Xorg in 2021 unless you really know what you're doing. It's not secure unless you take great pains to make it so. GNOME's Wayland session is the most secure Linux desktop there is outside of security-focused distros.

[nextaccountic]

I think the main (or only? not sure) culprit is Firefox (running natively on Wayland) https://bugzilla.mozilla.org/show_bug.cgi?id=1726360 - it reports to be fixed in Firefox 93 but I'm on Firefox 92 still, I guess I should just update.

> And I don't think there is much incentive to support this from a hardware perspective either since most people that I see asking for this are using it as a workaround for oddly sized 4K monitors.

All 14" hidpi laptops (meaning, more than 1366x768) suffer from this problem. 1x is too small, 2x is too large.

[md8z]

Those laptops I think would fall in that same category of displays, where the PPI is around 120-180. It's not enough of an enhancement to make the text crisp and not pixelated, and it makes everything look bad unless the apps native to 96 PPI start to implement a certain type of floating point scaling. The higher end laptops of the same size just give you a the same screen but with a higher PPI. Scaling up then scaling down doesn't cause noticeable blurring once you get past 250 PPI, so it's only that class of low end displays/laptops that would benefit from this. I wonder if those displays will even still be around in a few years time, I certainly would like to get a cheaper laptop around that size but with a higher PPI.

[nextaccountic]

From my point of view, my screen - 1920x1080 at 14", at 189ppi, isn't really what I would call low end. Or at least, not in my country (Brazil).

Low end is 1366x768 at 14", which is 135ppi. Most laptops I see have this resolution.

[md8z]

I mean low end in the category of high DPI laptops. I think that would be considered mid range in the category of all laptops, that was my take from looking at prices recently anyway. There are high end laptops that are around the same size and have 4K screens.

[cycomanic]

> think the main (or only? not sure) culprit is Firefox (running natively on Wayland) https://bugzilla.mozilla.org/show_bug.cgi?id=1726360 - it reports to be fixed in Firefox 93 but I'm on Firefox 92 still, I guess I should just update.

I was just about to write the same, the only clipboard issues I've had in wayland were with firefox. I don't know what they do, but even in windows I get weird behavior at times (e.g. when copying out of Jupyter cells for example), much less than wayland though.

[Aa9C4xPz43Gg7k6]

Lack of functional fractional scaling is what makes me want to switch to Windows or Windows+VM or Windows + ssh to compile.

[eecc]

Ah sorry... so the major issue is not with Wayland itself, but with the major toolkits that in 10+ years haven´t bothered or figured out how to transition away from a rasterized buffer model.

Right. It doesn't matter if the fault is with GTK, Qt or the Wayland APIs not providing enough support for this to happen, sometime in the last 10 years. The problem is that it didn't.

In the meantime I've been using MacOS that has been doing vector graphics since what? 15 years?

SMH...

[md8z]

This isn't about vector graphics. There is always going to be a rasterized buffer, that's unavoidable. Even more so as apps are moving to newer rendering APIs like Vulkan and Metal. Apps doing custom rasterization is probably going to get even more common. The real issue there is what scale you do the rasterization at, because some things just cannot be expressed in terms of vectors. I believe Qt does support doing floating point scaling in some cases [1] but I've heard it's really broken because the apps still need to make changes to support it. You can't just take any old Qt app and recompile it with the moral equivalent of "#define int float".

This is also not a matter of "fault", by necessity the majority of the work that needs to be done here in the toolkits and apps. That's just the way it is. It's not that hard to implement this on the server side, you just don't scale that buffer when rendering. MacOS is an not a good example because that also uses an integer scale.

[1] https://doc.qt.io/qt-6/highdpi.html

[eecc]

Ok, let me rephrase. What I mean is - how I see it - that Apple just made the choice for every developer and gave them a conceptual model and tooling that does not depend on individual pixels or require them to make an extra effort in adoption (because you know how that goes.)

It baffles me that Linux is still stuck on this pixel grid that just hangs together at a specific density of 96dpi; something that harks back to the VGA days

https://docs.microsoft.com/en-gb/archive/blogs/fontblog/wher...