No announcement yet.

The X API Is About 15 Times Bigger Than Wayland

  • Filter
  • Time
  • Show
Clear All
new posts

  • The X API Is About 15 Times Bigger Than Wayland

    Phoronix: The X API Is About 15 Times Bigger Than Wayland

    For those curious about the size of the X11 API in relation to Wayland, it's about fifteen times bigger...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Of course.

    It supports less functionality.


    • #3
      Less functionality = smaller

      This article is a bit misleading.

      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.

      How big is Xwayland, anyways?(I would assume it's not very large, but that misses the point) Wayland doesn't have the backward compatibility layer, its X which has the 'forward compatibility' layer, so to say. So by definition, X would have to be bigger.


      • #4
        Nor has it encountered the real world, yet. Right now it's a "battle plan", and battle plans seldom survive encounter with the enemy. That's not to say that it's not worthwhile, and can be an improvement over X. It's just that a year or two down the road, Wayland will have its ugly warts and bits of bloat, though it will no doubt still be smaller than X.


        • #5
          PART of Wayland being smaller is that while yes it has less features, it also has less things it has to support.

          Straight from the Wayland FAQ:

          What is wrong with X?

          The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to a optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.
          All opinions are my own not those of my employer if you know who they are.


          • #6
            135 entry points doesn't mean much, what if one of them is like ioctl(2)


            • #7
              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.
              Last edited by Silverthorn; 17 October 2012, 02:39 PM.


              • #8
                Originally posted by johnc View Post
                Of course.

                It supports less functionality.
                wrong, wayland protocol support most of the actually used features of Xorg already and it has some that are not possible with X11 protocol without a barbaric amount of hacks[like fps accurate animations].

                about missing features in 1.0 protocol will be network rendering but i agree this support should move client side, after all Kde/Qt --Gnome/GTK[etc] know better than anyone how they specific render code works
                for example:
                * Kde can reuse the local icons theme if present[or ask the user to install it] so it doesn't have to send images just pix identifiers to instruct the target wayland/kde to use those in your HDD
                * another example could be Qt/gtk introducing a meta renderer plugin that just instruct the remote Qt/wayland draw a Qcombobox with this properties at this position using X font, etc. so the actual local QT/gtk in the remote host do the rendering making the bandwith use extremely fast/easy to compress and encrypt, in fact this can allow you to use remote apps as any of your local apps, without worry about resolution or any other setting in your origin desktop/server,etc (many possibilities left to think about )

                about both project size, wayland will always be smaller than X11 since wayland is not a renderer, wayland is just a police that route commands to KMS/DRM/DRI/EGL/OPENGL/MESA/EVDEV/V4L/Overlays[<-- those one do the actual rendering] in a standard way so everyone can be on the same page.

                weston is just an example toy of how to do composite using wayland protocol instead of X11 that will make life easier for desktops devs to make the transition and well is a test client that wayland devs use to put some pressure in their code and iron bugs/errors


                • #9
                  Hopefully Wayland will have over 2,000 by 2.0, and beat xorg!!!


                  • #10
                    Originally posted by boast View Post
                    Hopefully Wayland will have over 2,000 by 2.0, and beat xorg!!!
                    Yeah, and by 3.0 it will be .. OVER NINE THOUSAAANNDDD!!!!

                    There's some pretty "small" articles today it seems, including this one.