[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...