Announcement

Collapse
No announcement yet.

Drafting Plans For X12, The X11 Successor

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

  • #11
    Wayland is a neat idea, but it's not a replacement for X11. Network transparency *does* matter, not only because people will always be running dumb terminals, but also simply because it necessitates clean design and standardized protocol.

    Wayland cannot replace X11 because it does not currently, nor does it aim to, provide a similar feature-set. X12 might. *Any* meaningful discussion of this is significant, because it is needed.

    Heck, there's nothing to say that X12 couldn't be built *on top* of Wayland. They're pretty much orthogonal in my mind.

    Comment


    • #12
      This is what I "understand" about network transperancy:
      I am a server, and there is another server somewhere, and I want to be able to render for the other server, so that other server can display my images instead of rendering it themselves, or I want to be able to have the other server render my images before sending them back to me, etc.
      Replace "render" with "do process" and "input", and "display" with "output", and this seems to be spot on from my limited observations.

      Comment


      • #13
        Originally posted by TechMage89 View Post
        Wayland is a neat idea, but it's not a replacement for X11. Network transparency *does* matter, not only because people will always be running dumb terminals, but also simply because it necessitates clean design and standardized protocol.

        Wayland cannot replace X11 because it does not currently, nor does it aim to, provide a similar feature-set. X12 might. *Any* meaningful discussion of this is significant, because it is needed.

        Heck, there's nothing to say that X12 couldn't be built *on top* of Wayland. They're pretty much orthogonal in my mind.
        Piping pixels is one of the least efficient ways to do network transparency. At one point you could get your whole application with the x draw commands and that was how people actually developed desktop programs. Anymore desktop programs are developed with C or C++ toolkits, and network transparency on the toolkit level is going to be a less bandwidth heavy way to do things. Even the idea of a dumb terminal is a comparitive thing. You can buy a really cheap ARM or MIPS SoC that will knock the socks off of anything we had in the 90's for under ten dollars. Sure it's not as universal, and it takes some more processing power, but it does save where a lot of dumb terminal setups have problems, and that is with total bandwidth.

        Comment


        • #14
          Originally posted by TechMage89 View Post
          Wayland is a neat idea, but it's not a replacement for X11. Network transparency *does* matter, not only because people will always be running dumb terminals, but also simply because it necessitates clean design and standardized protocol.

          Wayland cannot replace X11 because it does not currently, nor does it aim to, provide a similar feature-set. X12 might. *Any* meaningful discussion of this is significant, because it is needed.

          Heck, there's nothing to say that X12 couldn't be built *on top* of Wayland. They're pretty much orthogonal in my mind.
          at some point it will provide the same functionality.

          and apart from that i think i trust the people that actually write code for wayland more than the ones bitching about network transparency and client side stuff on the mailing lists and forums

          Comment


          • #15
            Originally posted by BlackStar View Post
            From my POV, the Wayland approach to GPU framebuffer composition appears an order of magnitude more efficient to anything involving composition in system memory over a network socket.
            This statement is non-nonsensical. You're attempting the compare the method the server uses for composition with the method the server uses for communication with the client. While they are not entirely disjoint(faster communication between server and client means more objects can be composited by the server), your attempt is frame them a mutually exclusive is illogical. Also you understanding of how Wayland composites is also backwards. It's currently X that uses frame buffers while it communicates with the compositor on what to to render.

            Originally posted by BlackStar View Post
            Besides, as GTK3 demonstrated there are ways to render seamlessly over the network at the toolkit level, without involving X.
            This is patently false.
            Originally posted by TechMage89
            Heck, there's nothing to say that X12 couldn't be built *on top* of Wayland. They're pretty much orthogonal in my mind.
            This is true. Wayland is a compositor that doesn't have to run with an X server, however it is not a replacement for it.

            Comment


            • #16
              X11 may be outdated but for many people it's working well. The biggest pain for users (I am not talking about developers) is perhaps the outdated X Screen protocol with its problematic dual-head, multicard and hybrid graphics support.

              Comment


              • #17
                Originally posted by siride View Post
                Another idiot who doesn't understand how X11 and network transparency.

                There's nothing about network transparency that says you can't share buffers like in Wayland when the client and server are on the same machine. Just like X11 currently uses fast local sockets and shared memory for communication on the local machine, X12 could do the same with buffers. In fact, X11 already uses shared memory to send large amounts of data between the client and server. It's a little clunky, but it could be cleaned up.
                James Gosling argues, on a paper from 10 years ago, against network transparency. He talks about how he would re-invent a modern graphics system and his thoughts match 100% the Wayland design. Basically this is just common sense and I find odd how long the current flawed design has survived trough the years. Other than unix most other systems have had much better graphics infrastructure, i.e. leaner and meaner.

                Window System Design:
                If I had it to do over again in 2002.

                James Gosling
                December 9, 2002


                In the deep dark past I have been involved in building window systems. I did the original design and implementation of both the Andrew and NeWS window systems. Both of which predated X11. They shared with X11 the architectural feature of being networked: clients sent messages to the server over TCP connections. I occasionally get asked “if you had to do it over again, what would you do? Would you do the same thing”. The answer is a strong no. It’s now 20 years later, and the technological landscape is totally different. So here is what I would do. But first...
                Last edited by zoomblab; 16 October 2011, 03:16 PM.

                Comment


                • #18
                  Originally posted by Milyardo View Post
                  This statement is non-nonsensical. You're attempting the compare the method the server uses for composition with the method the server uses for communication with the client.
                  Wayland is both a server and a compositor, so it does not make sense to distinguish between communication and composition. Indeed, the most common communication between the server and a client is "my buffer is ready for composition" (client->server) and "redraw yourself" (server->client).

                  Why is this important? Because, unlike X11, Wayland can access the client framebuffer and compose directly in GPU memory. This is impossible in the current X11 architecture and will remain impossible unless the compositor can make some assumptions that cannot currently be made. What compiz, mutter, kwin currently do is copy of the contents of each X window pixmap into a GLX pixmap, upload this to an OpenGL texture and compose these textures on screen.

                  Not only is the Wayland approach faster, it is also simpler to implement and much more robust. How anyone could consider the X approach sane or desirable is beyond me. Just consider that it's 2011 and X still cannot display an image on screen with proper vsync.

                  Also you understanding of how Wayland composites is also backwards. It's currently X that uses frame buffers while it communicates with the compositor on what to to render.
                  See above. Wayland uses KMS buffers, the rough equivalent of OpenGL framebuffers (which is what my terminology was refering at).

                  Comment


                  • #19
                    Maybe what we really need is a good method of abstract UI structure/layout/event serialization (which of course would be grudgingly standardized after about 50 years of debate, just in time to be obsoleted by retina-mounted voxel displays). That would allow both network transparency at the UI level and greater flexibility in the final rendering. Why should most application processes have any sense of "the display", even one encapsulated by a toolkit library?

                    Comment


                    • #20
                      Originally posted by 89c51 View Post
                      at some point it will provide the same functionality.
                      No it won't, because it's not meant to. For example, X includes functionality to render lines and ellipses and arcs and whatnot, and Wayland will never include this, because the Wayland developers believe that this shouldn't be done in the display server.

                      Comment

                      Working...
                      X