If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

There is another potential design issue for Wayland though, it only knows about full window buffers, when displaying remotely text (an important use case), it's quite possible that this will lead to much worse performance than X: with XRender an application can just say draw this (already cached) glyph, whereas for 'stock Wayland' to display one character you either have to send a full buffer (much higher bandwith used) or you implement compression but this adds latency and is a bit stupid from a design POV (undoing what you just did) or .. you keep using X11(X12?) on top of Wayland.

Now X is so old and crusty that it has also lots of performance issues.. So we have to wait until the Wayland developers implement remote display to check the real performance difference between both solutions...

Can you just send the delta (which is probably actually what video compression would do)? I think I've read things in that sense.

Comment

There is another potential design issue for Wayland though, it only knows about full window buffers, when displaying remotely text (an important use case), it's quite possible that this will lead to much worse performance than X: with XRender an application can just say draw this (already cached) glyph, whereas for 'stock Wayland' to display one character you either have to send a full buffer (much higher bandwith used) or you implement compression but this adds latency and is a bit stupid from a design POV (undoing what you just did) or .. you keep using X11(X12?) on top of Wayland.

Now X is so old and crusty that it has also lots of performance issues.. So we have to wait until the Wayland developers implement remote display to check the real performance difference between both solutions...

Wayland doesn't support server side rendering (XRender) because of lie that applications don't use server side rendering.

Comment

There is another potential design issue for Wayland though, it only knows about full window buffers, when displaying remotely text (an important use case), it's quite possible that this will lead to much worse performance than X: with XRender an application can just say draw this (already cached) glyph, whereas for 'stock Wayland' to display one character you either have to send a full buffer (much higher bandwith used) or you implement compression but this adds latency and is a bit stupid from a design POV (undoing what you just did) or .. you keep using X11(X12?) on top of Wayland.

Now X is so old and crusty that it has also lots of performance issues.. So we have to wait until the Wayland developers implement remote display to check the real performance difference between both solutions...

But currently with remote X applications for each glyph draw you are chatting to and and from the X server for that server side draw operation right?

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.

Comment

But currently with remote X applications for each glyph draw you are chatting to and and from the X server for that server side draw operation right?

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.

It should be possible to draw wall of text using single call with something like binary HTML.
Complete screen would be encoded in few kilobytes.
Doesn't XCB use something like that?
Sending text as bitmaps is retarded.

Comment

It should be possible to draw wall of text using single call with something like binary HTML.
Complete screen would be encoded in few kilobytes.
Doesn't XCB use something like that?
Sending text as bitmaps is retarded.

Using "something like binary HTML" is a slight of hand way to say you want to put rendering commands into the server .-)

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.

Comment

I don't use Radeon hardware. Glamor will maybe become as fast as Intel SNA, but it can take years. Glamor will have to be supported by GTK/Cairo/Qt as Wayland does no rendering.
Memory usage won't be probably solved as it is likely limitation of OpenGL.

GLAMOUR takes a rendering model that is inherently antagonistic to how modern GPUs work and tries to mske it fast. Toolkits need to intelligently render their widget graphs in a GPU-efficient manner, not use bad 2D APIS with some expectation of a lower level making it all right. I think Qt is moving there; GTK has a lot of work to do. To be fair though Windows' myriad of toolkits are generally just as bad; even ones using D2D generally use it wrong and end up slower than CPU-based rendering in many cases. Even many games just use Scaleform, which is helluva inefficient compared to what a knowledgeable dev with enough time/budget can do.

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.

Comment

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.

He's referring to compositing in the terms of desktop effects. Which in reality what he's referring to is Indirect Rendering.

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.

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.