Announcement

Collapse
No announcement yet.

Wayland's Weston Now Handles Full-Screen X Windows

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    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.

    Comment


    • #32
      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, 11:03 AM.

      Comment


      • #33
        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)".

        Comment


        • #34
          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.

          Comment


          • #35
            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.

            Comment


            • #36
              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.

              Comment


              • #37
                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.

                Comment


                • #38
                  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.

                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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

                      Comment

                      Working...
                      X