They are definitely worth going through and Manuel Stoeckl deserves a lot of good karma for taking this on.
The problem is that the old model has some limitations that make it impractical to use these days. For instance, modern anti-aliased fonts need to be drawn on the client side and sent over as bitmaps. There's also no good way to do double-buffering or otherwise avoiding the display of partially drawn frames.
So if the X.org maintainers decided to re-focus on server-side drawing, this could be made to work better. But they've decided to go in the other direction and draw everything client-side in Wayland, so that's the way the toolkits are going to be designed.
Xft is drawn 100% server side
> But they've decided to go in the other direction
They made the wrong decision.
No, that's blatantly wrong. libXft is a client library that uses the X RENDER extension's Glyphs functionality to upload glyphs rendered by FreeType on the client to the server. Glyph compositing happens on the server, but that's not even Xft; just X RENDER.
Again, you can look at libXft, the client-side library, to see that all glyph rendering is client side: https://github.com/freedesktop/libXft/blob/master/src/xftren...
> They made the wrong decision.
GTK+ tries as hard as it can to use the X RENDER extension to draw all shapes server-side. Like, really hard to do that; I couldn't find any place where it was unnecessarily falling back to client rendering. And yet when I looked at how many GTK+ applications were server-rendered, the number was very tiny.
This is a complex problem a lot of people have worked on, with lots of non-obvious tradeoffs and the peanut gallery going "we made the wrong decision" is frustrating.
Not really "blatantly" wrong. Once the Glyps are transmitted to the server cache they can be redrawn infinitely without causing much bandwidth or round trips.
The fact that they are not entirely rendered server side is again a totally stupid decision. Now even the same font can look completely different on the same system dependent on which freetype parameters some app developer chooses. Now the fonts for Gtk, Qt, Wx or fltk apps can all look completely different (E.g. use different sub-pixel rendering) if not configured properly.
The original GTK+ is not the problem and works actually quiet well. Gtk2.0 and onward as well as any newer QT version are the problem. Gtk2.0 has many replacable rendering engines most of them don't care one bit about remote operation. They are certainly not "trying really hard" to do that.
Because funnily enough, the network transparency of X is in direct conflict with the evolution of GUI applications and toolkits: if a new server-side capability is required, it would only be present in a new version of the X server, and when the X server is remote… well, it could be anything, it could be an ancient version on a system that will never be upgraded, or an alternative implementation like VcXsrv for Windows.
Also the ability to upload pixmaps and blit them afterwards as much as you want without causing much bandwidth exists since the earliest version of X11. The offending toolkits are not even using that. They blit client side and transmit the result every time. As I told you, they are stupid.