1. 19
  1.  

  2. 6

    I don’t know much about X11 or graphics programming but was able to follow this at a conceptual level.

    Is this the direction Wayland ended up going or were different decisions taken with its design?

    1. 10

      Some the same, some different. They’re generally based on the same principles, but where Wayland draws the lines isn’t always where this (excellent) article does. My somewhat limited understanding and comparison is as follows:

      Each graphical application gets direct access to the hardware, and a window is nothing more than a clipping list and an (x,y) translation

      Wayland working through OpenGL is even a little lower level than that, a window is just a buffer of pixels to output to. Clipping lists are less important because a compositor… well, does the compositing for you, blitting together multiple windows into a final framebuffer that gets shown on the screen. GPU’s can help with this process a lot more than they could in 2002, when doing off-screen rendering and layering together multiple render passes was expensive and uncommon.

      It doesn’t just maintain clipping lists. It maintains the “true shape”of each window, and a stacking order. The windows clip is derived from these by subtracting from the clip for a window the shapes of all of those above it…

      Again, Wayland itself is a little lower level. The actual Wayland protocol/API says nothing about any of this, it’s entirely up to the compositor implementing it how it wants to arrange and communicate between windows.

      [The windowing system] has to handle resource allocation within the accelerator, including texture space and rendering ports.

      Yep, Wayland does this.

      The mouse driver would need to have an association between clipping lists and processes to deliver events to. It is the natural place for one small piece of UI policy: that once a mouse button goes down, all following events get delivered to the same process until all buttons are up.

      This is left entirely up to the compositor again. It just gets a stream of input events and handles the multiplexing itself, delivering them to whichever window it thinks should get them.

      It is quite likely that the keyboard and mouse driver should be merged at the higher levels so that applications have one file to read events from.

      IIRC, which I’m not sure I do, Wayland effectively does this. It’s more complicated than that because there’s lots of other events as well, particularly things like monitors or mice or such being attached/disconnected, which nothing really handled well in 2002, and was less common because laptops weren’t quite as pervasive.

      Almost everything else would be done at user level, in the user process: rendering, window borders, and the hard parts of cut/paste/drag/drop. … The kernel knows nothing of the details within a window.

      Yep, exactly what Wayland does.

      So all in all, a lot of things are similar but not exactly the same. A lot of the difference is Wayland refusing to dictate policy. A little bit of it is due to hardware evolving in different ways than anticipated, but for being written in 2002 I find this incredibly prescient. Advantages to long and deep experience, I suppose: you can look at what the trends are and how they change.

      1. 2

        Thank you so much for the detailed answer. I read it and immediately afterwards saw https://tudorr.ro/blog/technical/2021/01/26/the-wayland-experience/ show up.

        Having this background made me enjoy that article even more 🙌