> It is far easier today than it ever was before to make a Wayland-> based > environment.
> [1]: https://isaacfreund.com/software/river/ > [2]: https://github.com/Miriway/Miriway > [3]: https://wayfire.org/ As far as I know, these projects, only handle window state, and perhaps DRM KMS as well. Since I do not have the time to dig into these projects' respective documentation, I can only surmise to the following: Pixmap-equivalent objects still have to be handled by the compositor developer, and as far as I know, draw calls also have to be handled by the compositor developer. The compositor developer basically has to be a graphics programmer, if they want their DE to be GPU-accelerated (via merely copying and drawing rectangles). Or, they will have to use a library like Raylib. Fortunately, wlroots has a rendering abstraction, so some of these concerns can be abated. However, I don't know whether the abstractions provided by wlroots are as clean as X11's. X11 basically handled these concerns from the beginning, and so all basic X11 applications were GPU accelerated by default, unless they were SW rendering to a pixmap or something. Of course, fancy UI features outside of drawing/copying rectangles and text, still required an X11 compositor, however, X11 still handled the majority of the complexity in regards to these operations, including the relevant memory buffers. X11 is basically a 2D GPU raster API + window handler in one, which makes it very fast at its job, even today (Wayland compositors are usually fast, too). I should note that Wayland clients are made more complicated because of this problem, as well. Thus, UI frameworks, like GTK and QT, are now required to be more monolithic, and handle more responsibility within the UI stack as a whole. These UI stacks were already complicated enough. Basically, the maintenance of graphics layers within Linux's UI desktop software, has been split across several projects, when this maintenance used to only be in one spot, as far as I know. Due to this, I believe that the maintenance of this software will become a significant problem in the near future, for *both* X11 *and* Wayland. Sent with Proton Mail secure email. On Tuesday, June 30th, 2026 at 13:55, Neal Gompa <[email protected]> wrote: > On Tue, Jun 30, 2026 at 1:14 PM CS Sushi Man via devel > <[email protected]> wrote: > > > > > Speaking of the future: How much effort do we (does someone) want to put > > > into a DE which requires an X11 stack? > > > > It is far easier for a DE developer to maintain an X11 DE, since > > they would only have to be concerned with having certain pixmaps > > and rectangles drawn to the screen (like a titlebar), and some > > input handling (like pressing the close button on a window). > > Wayland on the other hand, requires a DE developer to maintain > > their own compositor, which may also include dealing with GPU > > memory management, handling rendering calls, handling input devices > > directly, and things of that nature. The "DE" would now have to > > store window locations, handle BLIT operations, handle the mouse, > > handle display planes, framebuffers, and everything related. Pretty > > much, the DE would now have to handle all the things previously > > handled by the X server. > > > > It is *far* easier to maintain an X11 DE, than it is to maintain > > a Wayland DE/compositor. The DE maintainer, with X11, is only > > concerned with how the user may interact with his machine, and to > > forward those interactions to the X11 server accordingly. The DE > > does not have to store window locations, mouse locations, or > > anything of the like, since the DE can simply query them from the > > server. The DE does not have to manage GPU memory, since X11 does > > this for you via pixmaps. X11 will also handle BLIT operations, and > > rectangle copies/draws. > > > > With the Wayland protocol, the DE maintainer would be required to > > make his own compositor, since the Wayland protocol does not allow > > for these queries whatsoever. This does make the protocol itself > > simpler, but it comes at the cost of combining a significant number > > of responsibilities into one program, which were previously handled > > separately. > > > > Maybe in the beginning that was true, but today it is not. > > There are multiple stand-alone compositors that can be integrated into > desktop environments. River[1], Miriway[2], and Wayfire[3] are three > good examples, and two of them (Miriway and River) are designed to be > integrated into a larger experience. River gives you a similar > architecture to X11 where you can write a window manager that > leverages the River Wayland server, and Miriway is designed as an > extensible and configurable compositor built on Mir. > > It is far easier today than it ever was before to make a Wayland-based > environment. > > [1]: https://isaacfreund.com/software/river/ > [2]: https://github.com/Miriway/Miriway > [3]: https://wayfire.org/ > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
