So for a screen full of text (lets say) you have to ask the X server to perform each individual glyph draw. This has round trip and protocol overhead (you mentioned latency, well here is where a bunch will live).
My gut says it's gonna be much more performant to draw that wall of text client side and send one big buffer update. One blob instead of lots and lots of roundtrips with the associated socket synchronisation code.
You can also do funky things like rate limiting client side so you aren't trying to update the display too often, keeping the wire saturation to a reasonable level. You can't do this with server side drawing operations.
If you're only drawing the odd bit of text here and there - then the use of deltas (as someone mentioned) becomes the method to do it.
Waylands "remoting" isn't fixed in stone so it's a little early to tell, but I think the gnashing of teeth is a little pre-emptive, to be honest.
I feel I should mention that XCB font rendering is old X style corefonts. Which are ugly and why we had Xft and Xrender come about.
Now glyph rendering using Xft and Xrender does indeed store the glyph map server side - but it's generated client side and suffers from the problem I mentioned before - it's chatty for a wall of text.
GPUs are all about minimizing state changes and batching draw calls. Rendering many individual "primitive" 2D elements and using non-atlased pixmaps/glyphs is just bad. The lower layers can do some auto-magic batching, but the toolkit can do way more, and can expose a more appropriate drawing API to apps/themes. Clutter hence is way more interesting than GLAMOUR.
In Wayland, clients draw and submit complete frames of their window. This means that the server has always a consistent image ready of the window content (unlike in X). We have many clients sending their frames. The compositor must then combine these images to a complete picture of the desktop, and put it on the display. This is compositing: combining images to make a big picture. If you don't composite, you cannot see multiple windows at once.
So why does it make a difference in X when you "disable compositing"? When you composite in X, the window image from a client goes to the X server, from the X server to the compositing manager, the compositing manager composites, the compositing manager sends the big picture to the X server, the X server puts the big picture on display. When you do not composite in X, the image goes from client to the X server, the X server combines the images of many clients into a big picture, the X server sends the big picture to display. See the difference?
Or rather, see the similarity? The X server is combining several images into a big picture. But that is... compositing! Whether you have a compositing manager in X or not, there is still always compositing happening, since you are able to see more than one window at a time. Ok, actually X server's own compositing is just poor man's compositing: when it comes the time to paint a newly exposed area, X will ask a client to paint it instead of just doing it. Then you will wait and watch garbage until the client, if it happens to be responsive, paints.
You are right, in Wayland you cannot disable compositing with non-fullscreen windows. It would simply not make any sense. There is also no third-party program doing the compositing like with X compositing managers, adding communication delays and complexity.
Or did I interpret you wrong, and you actually meant that compositing is actually useful, cool, and good? Which it is, when done properly.
Direct Rendering:Code:Input -> X Server -> X Client -> X Server -> Compositor -> X Server -> Image is displayed
Wayland Rendering:Code:Input -> X Server -> X Client -> X Server -> image is displayed
Since the Wayland Server IS the compositor (kwin, mutter, compiz) There's no performance drop unless they hit a slow code-path or bug in the compositor.Code:Input -> Wayland Server -> Wayland Client -> Wayland Server -> Image is displayed
With indirect rendering there's a slow down (What he's talking about), with Direct rendering there's no slowdown. And with Wayland rendering there may even be a speedup in rendering time, and therefore better FPS, because they dont have to work around all of X's bloat and cruft and legacy crap.