![]() And by quickly looking through its source code, it looks like it benefited massively from wlroots and from the scene graph API, plus all the other Wayland protocol extensions that are implemented ready-to-use in wlroots. Looks like nothing I've seen before in the ricing space. It's a nice dynamic tiling compositor, but it also has some very slick graphics, animations, config system. IMO, this actually leaves room for less bugs, and all around a much better, and stable, experience, than what one would get with an X11 WM + a X11 compositor on top.Īnd, looking at this compositor, Hyprland, it looks like just that. While it is true that a Wayland compositor programmer has to code by hand a lot of boilerplate as I explained in the article, now that the absolute ugliest yet-still-essential parts have been abstracted away in the scene graph API (before, if you didn't implement damage tracking, you had to basically say goodbye to your laptop's battery), besides the other ugly yet-still-essential parts that are already the entirety of wlroots, now compositor writers have the sweet-spot where they can integrate the special behaviour their compositor is all about with nicer graphics, rendering, input handling etc. It is hard to quantify how much buggy, or less buggy, are "amateur" Wayland compositors compared to their X11 counterparts. The situation changed a little bit since I published the post, which is that wlroots finally gained upstream the scene graph API, which abstracts away a lot of the painful parts of compositor development, mostly the parts about rendering windows and damage tracking. I'm the author of the mentioned blog post. "With Wayland, you handle everything, even with wlroots." wlroots doesn't abstract everything away, it just gives you a bunch of useful tools. I can't say I've ever attempted it myself, but if you take a look at the blog post above, the author is very clear on the fact that even with the benefit of wlroots (which they highly praise) writing a Wayland compositor is still a lot more work than writing an X11 window manager (which they have also done, so they are something of an authority). ".there is still a lot of boilerplate involved in writing a compositor, much more than for an X11 window manager, namely setting up your own rendering code, registering and storing input devices and screens in your own data structures, passing input events to windows, calculating bounds for bars and other overlays (courtesy of layer-shell) and others. I trust "weird" compositors much less than I trust "weird" X11 window managers - it's more like using an alternative Xorg than an alternative WM. This in turn affords many more opportunities to introduce bugs, missing functionality etc. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. ![]() The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |