There's so many ideas and separate things/topics in this: a protocol between the Wayland server and your client, an RPC mechanism, a protocol format serialisation, synchronization (lock), an async mechanism, an object registry, shared memory, domain sockets, event loop.
Now I haven't written any non-CLI GUI Linux applications in C. I once played with the Qt IDE. I feel it is pretty difficult stuff!
I think dbus is also really interesting too.
This causes me to think of the success of Nodejs and how it abstracts async and makes it approachable to anyone. Rather than pointers in C you have JavaScript object literals.
The most complicated GUIs I created were with Swing in Java and JavaScript.
Can someone more knowledgeable tell me what is GPU accelerated with Wayland? Is there a bitblit operation uses by compositor? And how would you write a high performance GUI that is maintainable. I'm aware Blink/Chromium uses Skia which I presume is accelerated.
In my JavaScript visualisation experiments with canvases - the page has started to slow down because I'm doing stuff on the main thread.
I feel this would be so much harder to build in C.
I am kind of following the trends in GUI rendering tech - I am curious how you support rendering lists of hundreds of thousands of items without expensive update costs. The perennial react performance problem.
I'm following the approaches taken by Tauri and Rust desktop app designs. Looking for a silver bullet.
It's protocols which handle the communication between GUI toolkits your desktop manager (e.g. make new windows, resize windows, scaling, etc.) and how to connect to the GPU driver.
I.e. wayland isn't GUI technology it's a level below it.
So on systems using Wayland every GUI toolkit, including Skia, uses Wayland internally.
Also Wayland is _only_ protocols, so questions like "is window composition GPU accelerated" are implementation details of the specific compositor (through yes in general they are).
This is also on of the differences with X. Another one is X had a bunch of features sprinkled in which belong to the space of GUI toolkits (most of which had been abandoned by most software long before Wayland become relevant). Wayland is more cleanly designed wrt. to this aspects.
Going further, protocols of Wayland are also notably about passing filehandles to GPU memory (DMA-BUFs) to the compositor. The client allocates the memory, the client draws to it, however it wants, and it uses the Wayland protocols to pass reference to what's it's drawing to the compositor. https://wayland-book.com/surfaces/dmabuf.html
In contast, X was born before os had anything like dma-buf. X has all kinds of tools for drawing.
There's a lot griping about how Wayland isn't a monolithic server, how different compositors have to reimplement base capabilities and how this could lead to incompatibilities or different capability sets. Personally I think the fear uncertainty & doubt is overblow (open progress and possibility trumps conservative consistency), but I think what's technically interesting about how Wayland compositors work is that the Wayland design leaves so much more to the OS & client than X did. It makes it much more feasible to make a new compositor, since really Wayland is just a buffer manager, for os buffers, allocated by clients. This reinforces, to me, your proposition that Wayland is much more clean, by having to invent so very much less than X had to invent (and it truly had to, there we're not good os level constructs to use, the time).
The problem there is that the Wayland protocol family is not tolerant of dropping events or buffering them indefinitely, so there is no benefit to an X server-like architecture where you can transparently restart or replace the compositor. You're welcome to try, of course, but there are an incredible number of scenarios that break clients; one off the top of my head is if the mouse cursor creates a client tooltip by hovering over some GUI element, then leaves that region while there is no compositor to handle the mouse movement events. You're going to end up in a world where you're synthesizing fake events to "reset" the state of clients, and this is dragons-at-the-edge-of-the-map territory.
I wish Wayland was architected around a state-synchronization model instead of being event-driven. It'd be extremely difficult to port client toolkits and would ultimately fail to attract adoption, of course, but you'd end up with a more resilient system overall, and one that could be a bit more implementation-agnostic.
The problem is we have to use Wayland now, but the ecosystem isn't quite at X11 levels. Most documentation and tutorials are X11.
Wayland will probably be amazing like many of other technologies I've ever disliked in the past (Some of them still seem to suck though!) but right now it's still effectively brand new on the general user scene.
dma_bufs can’t cross machine boundaries, so Wayland not being monolithic requires deploying another service directly onto the user’s desktop machine and having it draw everything on behalf of all the GPU-less app servers. In practice the web browser strangely takes this role, with Javascript or Wasm as both window manager and rendering API, but in this world I’m not sure why the compositor still needs to be there.
Now I haven't written any non-CLI GUI Linux applications in C. I once played with the Qt IDE. I feel it is pretty difficult stuff!
I think dbus is also really interesting too.
This causes me to think of the success of Nodejs and how it abstracts async and makes it approachable to anyone. Rather than pointers in C you have JavaScript object literals.
The most complicated GUIs I created were with Swing in Java and JavaScript.
Can someone more knowledgeable tell me what is GPU accelerated with Wayland? Is there a bitblit operation uses by compositor? And how would you write a high performance GUI that is maintainable. I'm aware Blink/Chromium uses Skia which I presume is accelerated.
In my JavaScript visualisation experiments with canvases - the page has started to slow down because I'm doing stuff on the main thread.
See this example - scroll down and you'll see a process visualiser and scroll down further and there's a graph. I'm doing parsing on the main thread https://replit.com/@Chronological/Processes3#index.html
I feel this would be so much harder to build in C.
I am kind of following the trends in GUI rendering tech - I am curious how you support rendering lists of hundreds of thousands of items without expensive update costs. The perennial react performance problem.
I'm following the approaches taken by Tauri and Rust desktop app designs. Looking for a silver bullet.