Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 59

Thread: Wayland's Weston Now Handles Full-Screen X Windows

  1. #31
    Join Date
    Sep 2012
    Posts
    662

    Default

    Quote Originally Posted by renox View Post
    I 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...
    Can you just send the delta (which is probably actually what video compression would do)? I think I've read things in that sense.

  2. #32
    Join Date
    Sep 2012
    Posts
    328

    Default

    Quote Originally Posted by renox View Post
    I 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...
    Wayland doesn't support server side rendering (XRender) because of lie that applications don't use server side rendering.
    Last edited by JS987; 02-15-2013 at 11:03 AM.

  3. #33
    Join Date
    Mar 2012
    Posts
    83

    Default

    Quote Originally Posted by erendorn View Post
    Can you just send the delta (which is probably actually what video compression would do)? I think I've read things in that sense.
    That's what I wrote in fact: "or you implement compression" but as I said: "this adds latency and is a bit stupid from a design POV (undoing what you just did)".

  4. #34

    Default

    Quote Originally Posted by renox View Post
    I 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...
    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.

  5. #35
    Join Date
    Sep 2012
    Posts
    328

    Default

    Quote Originally Posted by silenceoftheass View Post
    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.

  6. #36

    Default

    Quote Originally Posted by JS987 View Post
    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.

    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.

  7. #37
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by JS987 View Post
    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.

  8. #38
    Join Date
    Oct 2008
    Location
    Finland
    Posts
    59

    Default

    Quote Originally Posted by JS987 View Post
    Wayland can't disable compositing for non-full screen applications.

    WebGL Aquarium
    https://webglsamples.googlecode.com/.../aquarium.html

    without compositing
    50-55 fps
    with compositing
    40-45 fps

    XFCE, Chromium, window maximized, Intel GPU, latest drivers
    What 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.

  9. #39
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,874

    Default

    Quote Originally Posted by pq__ View Post
    What 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.
    He's referring to compositing in the terms of desktop effects. Which in reality what he's referring to is Indirect Rendering.

    Indirect Rendering:

    Code:
    Input -> X Server -> X Client -> X Server -> Compositor -> X Server -> Image is displayed
    Direct Rendering:

    Code:
    Input -> X Server -> X Client -> X Server -> image is displayed
    Wayland Rendering:

    Code:
    Input -> Wayland Server -> Wayland Client -> Wayland 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.

    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.

  10. #40
    Join Date
    Sep 2012
    Posts
    328

    Default

    Quote Originally Posted by pq__ View Post
    What does "disabling compositing" mean for you?
    Disabled compositing - direct rendering using overlay.
    Wayland doesn't support overlays, but it seems it will be fixed.
    http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •