> For one very big thing, hardware accelerated rendering didn't exist in 1980. Then why the hell isn't it being used by GTK/Cairo nor Qt in production code. Oh

> For one very big thing, hardware accelerated rendering didn't exist in 1980. Then why the hell isn't it being used by GTK/Cairo nor Qt in production code. Oh yes, there are OpenGL(-ES) backends in both. But by far and large they're doing all their rendering on the CPU and then blit over to the graphics system. This is BTW the main reason for Wayland coming to be in the first place: The observation that the X server has been "reduced to a blitting engine" (if your world view is so narrow to cover only GTK and Qt). And then they're draining the baby with the bathwater… Wayland is how old now, 9 to 10 years, and it's still far from usable for production. IF you compare that with X11, after 10 years it didn't have just a barely working server and some example application. It was a thriving ecosystem with multiple desktop environments, toolkits, loads of production applications and you could just run them all arbitrarily in the same environment. Only last Friday I was working on a custom windowing library (something in the same vein as GLUT, SDL or GLFW, however with a focus on "desktop" programs with traditional GUIs instead of things like games) and whenever I start working with the Wayland side of things it turns into a severe headache. Wayland is an actively developer hostile (and I'd even wager to say user hostile, too) ecosystem. For example, because in Wayland there's no concept of windows, and whatever a window is, is left to the compositor, you can't even properly implement something like dockable windows. The best hack I could come up with was via the drag'n'drop mechanism that Wayland then does specify. IMHO Wayland is a prime example for the sunken cost fallacy hitting hard.