Announcement

Collapse
No announcement yet.

Wayland's Weston Now Handles Full-Screen X Windows

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

  • #41
    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?
    [cut]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.
    Totally wrong, in one X request you can draw several things.
    As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..

    Comment


    • #42
      Originally posted by renox View Post
      Totally wrong, in one X request you can draw several things.
      As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..
      Wayland should support server side rendering by linking with freetype, cairo, pango, etc.
      Last edited by JS987; 02-15-2013, 04:58 PM.

      Comment


      • #43
        Originally posted by elanthis View Post
        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.
        While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

        So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.

        Comment


        • #44
          Originally posted by Ericg View Post
          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.
          No, you are not describing indirect rendering here. All cases you describe can equally well be direct or indirect rendering, since you (nor I) ever mention who does the actual rendering of the client's image: the client or the X server. We were just talking about client provided images, not how they are originally created.

          Compositing or desktop effects have nothing to do with indirect rendering.

          The compositing manager in X might be (have been? Wasn't this limitation lifted?) limited to use indirect rendering for its own rendering only, but that has nothing to do with normal X clients.

          But that one is true that Wayland has less overhead: no indirect rendering (because all clients render full frames themselves, not pushing rendering commands to a server), and no communication with a third process (compositing happens within the server).

          Originally posted by JS987 View Post
          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
          Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.

          Originally posted by JS987 View Post
          Wayland should support server side rendering by linking with freetype, cairo, pango, etc.
          This comment makes no sense on its own. You would have to invent also a rendering protocol, which is an unimaginably hard task to do well.

          Comment


          • #45
            Originally posted by curaga View Post
            While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

            So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.
            1) Not all applications do this kind of rendering.
            2) You can cache several different glyphs for one character..
            I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
            The hard part is handling resynchronisation in case the server needs to reduce the cache size..

            Comment


            • #46
              Originally posted by pq__ View Post
              Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.
              Wayland without overlays does compositing using GL, which causes rendering to be indirect.
              The addition of atomic page flip to the kernel should allow the configuration of overlays within a frame boundary. This allows KMS Wayland compositors, such as Weston, to use overlays seamlessly. In this talk we'll cover how Weston assigns different surfaces to overlays and other planes, to reduce the portion of the screen that is composited using GL.
              http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

              Comment


              • #47
                Originally posted by JS987 View Post
                Wayland without overlays does compositing using GL, which causes rendering to be indirect.

                http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE
                two pass rendering != indirect rendering

                GL indirect rendering means that the application is unable to talk to graphic hardware - thus GL calls have to be submitted to the server which in turn submit them to the gpu (as it's the only one with hw access privilieges) - hence AIGLX

                compositing means that an application IS able to operate on the gpu (within the device context it has been assigned), hence direct rendering - but since only the compositor/wm/server knows about windows from ALL active applications, they render offscreen textures that the compositor then renders on screen
                hence a 2 pass rendering, or redirected (direct) rendering

                which may have some overhead over rendering directly to screen in a single pass, but if you think about it the latter would apply only to full screen applications and overlays

                Comment


                • #48
                  Originally posted by renox View Post
                  1) Not all applications do this kind of rendering.
                  2) You can cache several different glyphs for one character..
                  I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
                  The hard part is handling resynchronisation in case the server needs to reduce the cache size..
                  It's not enough to cache several iterations of some letter. They can also overlap (and the overlap can change just as the shape) and can change dynamically, meaning you would have to cache the overlap data, and with the possibility of per-letter changes, the amount of permutations becomes rather unwieldy.

                  Comment


                  • #49
                    Originally posted by curaga View Post
                    While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

                    So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.
                    For Arial one texture per font size is enough.
                    http://imageshack.us/photo/my-images...rendering.png/
                    click image to view in original size

                    Comment


                    • #50
                      Originally posted by silix View Post
                      two pass rendering != indirect rendering
                      2 pass rendering is indirect rendering.

                      Comment

                      Working...
                      X