Announcement

Collapse
No announcement yet.

The X API Is About 15 Times Bigger Than Wayland

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

  • #16
    Originally posted by Rigaldo View Post
    If I recall and understand correctly, X needs to do about 15 communications between applications for each resize event. (Possibly more, I think some where removed for simplicity from the example .. )
    In the same case Wayland can do with ~3.
    That's just part of what can be called bloat in X.
    Like much code not used by pretty much anything today, but needing to be maintained(and possibly loaded?).
    Btw, how well does your Raspberry Pi run compiz effects btw?
    What will compiz fusion do for the raspberry pi? It doesn't have enough CPU horsepower to run a compiz fusion desktop. THAT is where the bloat is, ON THE DESKTOP, NOT the X server.

    I'm NOT arguing against wayland, I think it's great! But BLOAT is not the reason to switch.

    If BLOAT was a legitimate reason to dump software then Windows would have been toast decades ago.

    New CPUs arrive with regularity, and yesterdays bloated mess is today's normal workload.

    Shit we used to joke that emacs was a terrible memory hog, but the modern Notepad uses more system resources, and now emacs (bigger than ever!) is slim and trim in comparison.
    Last edited by frantaylor; 10-17-2012, 05:23 PM.

    Comment


    • #17
      Originally posted by frantaylor View Post
      What will compiz fusion do for the raspberry pi? It doesn't have enough CPU horsepower to run a compiz fusion desktop. THAT is where the bloat is, ON THE DESKTOP, NOT the X server.

      I'm NOT arguing against wayland, I think it's great! But BLOAT is not the reason to switch.

      If BLOAT was a legitimate reason to dump software then Windows would have been toast decades ago.

      New CPUs arrive with regularity, and yesterdays bloated mess is today's normal workload.

      Shit we used to joke that emacs was a terrible memory hog, but the modern Notepad uses more system resources, and now emacs (bigger than ever!) is slim and trim in comparison.
      Ok, I meant that things X does can be done much more efficiently. And lags in some operations are visible. Except if even openbox is bloated ..
      I asked about compiz out of curiosity mostly. Bloat also has to do with code, as I mentioned.

      Comment


      • #18
        Originally posted by frantaylor View Post
        What will compiz fusion do for the raspberry pi? It doesn't have enough CPU horsepower to run a compiz fusion desktop. THAT is where the bloat is, ON THE DESKTOP, NOT the X server.

        I'm NOT arguing against wayland, I think it's great! But BLOAT is not the reason to switch.

        If BLOAT was a legitimate reason to dump software then Windows would have been toast decades ago.

        New CPUs arrive with regularity, and yesterdays bloated mess is today's normal workload.

        Shit we used to joke that emacs was a terrible memory hog, but the modern Notepad uses more system resources, and now emacs (bigger than ever!) is slim and trim in comparison.
        Bloat is a very significant issue to developers, specifically maintainers and newcomers trying to learn the "right way" to get a job done. In the end, happier developers equal happier users, so code bloat is a very good reason to reinvent the protocol. It's not about memory, or even performance, although both are also key points in it's favor, they're not the main issues. Like all new things, there will be growing pains, but in the end it should pay off very well.

        Comment


        • #19
          Originally posted by Silverthorn View Post
          Simply because Wayland lacks some features compared to X does not in any way imply that it has less features. Instead I would say that Wayland has more features than X due to it having exactly the capabilities which X lacks. The sections of X that will not be implemented in Wayland should be counted as a positive feature of Wayland.
          I couldn't agree more.

          Comment


          • #20
            The slowest thing I have ever ran compiz on is a mobile radeon M6 if I remember right only 8Mb vram... The windows wobbled fine... it did cause CPU load but this was on a Crusoe tm5800 (roughly equivalent to a p1 @ 400Mhz) so that isn't saying much. So really the compiz tax itself isn't that high even on X11.. and it should be lower on Wayland.

            Edit:
            It was also AGP 1x as the AGP 2x doesn't work properly on that system.

            Comment


            • #21
              Originally posted by frantaylor View Post
              What will compiz fusion do for the raspberry pi? It doesn't have enough CPU horsepower to run a compiz fusion desktop. THAT is where the bloat is, ON THE DESKTOP, NOT the X server.

              I'm NOT arguing against wayland, I think it's great! But BLOAT is not the reason to switch.

              If BLOAT was a legitimate reason to dump software then Windows would have been toast decades ago.
              You misunderstand the benefits of removing all these API entrypoints.

              It doesn't have anything to do with saving a few bytes of memory - it's about making the developers more efficient. Letting them add new features quicker, fix bugs more quickly, etc. That's a lot harder to do on a codebase with thousands of entry points, 95% of which are extremely poorly tested and hardly ever used, which has decades of hacks built on top of hacks. That's what the benefit is.

              Much of what X does has just been moved into the kernel, libdrm, and mesa anyway, so it's not like anyone should expect wayland to approach X. The whole point of wayland was to get rid of the stuff that nobody used anymore or that had already been moved elsewhere in the graphics stack but was kept around for backwards compatibility requirements.

              Comment


              • #22
                Originally posted by halfmanhalfamazing View Post
                There's probably a good argument to be made that Wayland can be(going forward) smaller and leaner than X is including the same features, or even adding in new features. But we aren't there yet.

                Right now, it's simply a matter of Wayland does less, so it's smaller. X does more, so it's bigger.
                A good bit of the difference is simply breaking up the functionality differently - X has API entry points for all the drawing routines, font handling, etc., though most modern apps don't use those. In the Wayland world, instead of baking that into the core API, you simply use complementary API's instead, such as Cairo, OpenGL, FreeType, FontConfig, etc. - for a direct functionality comparison you'd add all those to the Wayland count, but as they're modularized better they're easier to maintain and evolve as separate API's instead of hardcoded into the core like X11 did.

                Comment


                • #23
                  It would be possible to cut all the (almost) unused legacy stuff from X too; you would just have to call it X12 instead of X11...

                  Comment


                  • #24
                    Originally posted by alanc View Post
                    A good bit of the difference is simply breaking up the functionality differently - X has API entry points for all the drawing routines, font handling, etc., though most modern apps don't use those. In the Wayland world, instead of baking that into the core API, you simply use complementary API's instead, such as Cairo, OpenGL, FreeType, FontConfig, etc. - for a direct functionality comparison you'd add all those to the Wayland count, but as they're modularized better they're easier to maintain and evolve as separate API's instead of hardcoded into the core like X11 did.
                    Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.

                    Comment


                    • #25
                      Originally posted by JanC View Post
                      It would be possible to cut all the (almost) unused legacy stuff from X too; you would just have to call it X12 instead of X11...
                      But if we were doing a whole new, compatibility breaking, major release of X, such as X12, we'd want to take the opportunity to examine & redesign many other things about the protocol as well, not just dump the legacy calls. It would probably take some experimenting to figure out what works, and would need to be developed in parallel with X11 for a number of years, so that we didn't abandon all our existing users while designing for the future. In fact, it would probably be best to reduce confusion by not calling it X12 before it was ready, so people didn't think they could upgrade right away and get something better, but to develop it at first under a code name, perhaps the name of a town near the MIT campus where X was originally developed - maybe "Wayland"?

                      Comment


                      • #26
                        Originally posted by JS987 View Post
                        Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.
                        Yes it is supported. This is what the XWayland project is all about. Eventually, Cairo and other libraries that rely on XRender will need to upgrade to OpenGL. This is a good thing as XRender is already dying off today, and OpenGL is a cross-platform standard. Having a single, cross-platform API is a much better design for developers.

                        I don't know a whole lot about GPU driver development, but my guess is that eventually these API simplifications will make the closed-source AMD/nVidia drivers much more stable (once Wayland support actually happens). That would be awesome, because currently one of the biggest issues with Linux vs Window/Mac is poor driver support/performance on some hardware (I'm looking at you AMD).

                        Comment


                        • #27
                          Hopefully it's 15 times more awesome, too.
                          Last edited by blackout23; 10-20-2012, 03:42 PM.

                          Comment


                          • #28
                            Originally posted by JS987 View Post
                            Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.
                            Cairo's 'image' backend uses Pixman to do all the rendering - same as the server's software implementation of XRender.

                            There is one key difference though: using image and uploading the result via SHM is typically quicker (often much quicker) than using XRender, either accelerated or not. The only platform where it's reliably not so is SNA on Intel, which still isn't the default.

                            Thanks for your insightful post though.

                            Comment


                            • #29
                              Why I think Wayland is bad.

                              The only advantage of Wayland seems to be to get rid of some old APIs in X which are not used in modern programs. The problem is, those are required for backwards compatiblity. So instead of having to keep around a few old APIs, a switch to Wayland means that now Wayland + X has to be maintained (X for backwards compatiblity). This is making things more complicated instead of simpler. There is not even a very good reason for this, as the same things could be accomplished by extending X, as they admit on their FAQ:

                              > It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X.

                              Of course, Wayland proponents would say that I am spreading FUD, but to me the disadvantages are rather obvious: If X is kept only has a backwards compatiblity option, it will bitrot and eventually be removed from the default install. At that point, backwards compatiblity will defacto be lost. Also, forward compatiblity is immediately lost for all programs which rely on the Wayland API. They will not work with X. Maybe common toolkits will support both protocols for some time to mitigate some of those effects, but this too makes things more complicated instead of simplier.

                              For new programs, network transparency will be lost. Maybe some people do not see any point in network transparency, but I use it every day. With internet everywhere this is actually a feature which gets more useful and interesting in time. Also, people just do not seem to realize how cool this feature could be, if it would be further exploited instead of hidden from the user. Imagine moving a window of a running movie player from a mobile device to the TV when coming home... or all kinds of interactions which could be designed when people could move the windows of their computers to a common display and then the programs could interact by drag and drop or cut&past or whatever. Or just accessing your running X session from any device whatsoever and pick up work where you left. To me, the complete notion that programs run in a specific device and can only interact using the display of this device seems rather limiting and from pre-internet times, but this is exactly what switching to Wayland means for the future. Ofcourse, the common trend in GUI development on Linux seem to be to dumb things down, instead of letting the user fully exploit the technical potential of their system. In that sense, I can see that some people might think that network transparency is just not needed. I guess to some being able to play 3D shooters in a rotating window or similar useless crap is cool enough.

                              Comment


                              • #30
                                Originally posted by nnine View Post
                                For new programs, network transparency will be lost.
                                Network transparency will be lost at the display server. There's no reason it can't be built into higher-level toolkits/frameworks.

                                Comment

                                Working...
                                X