Originally posted by renox
View Post
Announcement
Collapse
No announcement yet.
Wayland's Weston Now Handles Full-Screen X Windows
Collapse
X
-
Originally posted by renox View PostI think you're right.
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...Last edited by JS987; 15 February 2013, 12:03 PM.
Comment
-
Originally posted by erendorn View PostCan you just send the delta (which is probably actually what video compression would do)? I think I've read things in that sense.
Comment
-
Originally posted by renox View PostI think you're right.
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...
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
-
Originally posted by silenceoftheass View PostBut 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.
Complete screen would be encoded in few kilobytes.
Doesn't XCB use something like that?
Sending text as bitmaps is retarded.
Comment
-
Originally posted by JS987 View PostIt 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.
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.
See: http://en.wikibooks.org/wiki/Guide_to_X11/Fonts
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.
Comment
-
Originally posted by JS987 View PostI 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.
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.
Comment
-
Originally posted by JS987 View PostWayland can't disable compositing for non-full screen applications.
WebGL Aquarium
without compositing
50-55 fps
with compositing
40-45 fps
XFCE, Chromium, window maximized, Intel GPU, latest drivers
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
-
Originally posted by pq__ View PostWhat does "disabling compositing" mean for you?
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.
Indirect Rendering:
Code:Input -> X Server -> X Client -> X Server -> Compositor -> X Server -> Image is displayed
Code:Input -> X Server -> X Client -> X Server -> image is displayed
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.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by pq__ View PostWhat does "disabling compositing" mean for you?
Wayland doesn't support overlays, but it seems it will be fixed.
Comment
Comment