Hello, yesterday I officially released Louvre v1.0.0, a C++ library designed for building Wayland compositors with a primary focus on ease of development. It provides a default method for handling protocols, input events, and rendering, which you can selectively and progressively override as required, allowing you to see a functional compositor from day 1.
It supports multi-GPU setups, multi-session (TTY switching), and offers various rendering options, including a scene and view system that automatically repaints only the damaged (changing) regions during a frame. Because it uses multiple threads, it can maintain a high FPS rate with v-sync enabled when rendering complex scenarios. In contrast, single-threaded compositors often experience a rapid drop in FPS, for example, from 60 to 30 fps, due to “dead times” while waiting for a screen vblank, leading to the skipping of frames.
The library is freely available, open source, thoroughly documented, includes examples, and features a detailed tutorial.
You can find it here: https://github.com/CuarzoSoftware/Louvre
I hope it proves useful for you. If you decide to use it and encounter any doubts or wish to contribute to its development, please don’t hesitate to reach out.
Greetings!
There’s desperate need to a library that’s simpler to use than wlroots or smithay - but unless it supports more protocols (later shell, gamma control, session lock), I don’t think this is a real a alternative yet.
I completely agree. I invest time in implementing protocols within the library, allowing it to handle many tasks autonomously, thus relieving developers from manually wiring everything themselves—without compromising flexibility oc. Regarding “later shell,” did you mean “layer shell”? Developers can certainly still implement protocols not included with Louvre on their own, but that’s not quite the intended approach.
ngl Im more interested in the dock and what protocols it uses. I’ve been missing latte dock since I migrated to wayland
The dock is rendered directly by the compositor in one of the examples; it’s not an external application as it ideally should be. It doesn’t rely on any intricate protocols or systemd services to monitor the states of apps. I added it solely for demonstration purposes.
Ah thats a shame, looks good however
I just use plasma panels these days
Is that desktop environment an apple UI clone?
Yes (kinda), that is a screenshot of one of the example compositors I included called “louvre-views” which implements server side decorations for apps that support the XDG Decoration protocol.
You mentioned it being easier then wlroots, but wayfire and phoc reportedly act as high level abstractions on top of wlroots that could be used to make it easier to create window managers (wayfire author explicitly mentioned it), Maybe it will be good to create a comparison with these projects? or even divert your future efforts to one of them?
I’m not sure if I explicitly mentioned that it’s easier than wlroots, but I believe its design can considerably ease the learning curve for newcomers. While I’ve read about those projects, I haven’t had the chance to try them myself. Although I’d be interested in contributing to their development, I don’t intend to abandon Louvre. I find it beneficial that there are different alternatives, as each can bring unique and clever ideas to enhance various aspects, ultimately improving the overall design across the board.
Neat
Do you plan to use vulkan wmi in any way?
Can xwayland be excluded?
Honestly, I haven’t explored Vulkan yet. I initially chose GLES 2.0 as the primary renderer to ensure compatibility with a wide range of hardware. Introducing Vulkan myself would be a time-consuming task unless I receive assistance.
Regarding XWayland, Louvre doesn’t currently support it, so it’s naturally excluded. Well, it technically can run in rootful mode, but that is somewhat pointless. To enable independent window management, I believe I would need to create a mini X server, a task I haven’t tackled as of now.
It looks very interesting.
I might be wrong, but it seems to me like Vulkan Support in hw is better than opengl:
- amd since at least Polaris (there is a project to Bring vulkan to really old terrascale graphics, but is jot yet there)
- Intel since idk
broadwellSkylake - Nvidia proprietary for sure don’t know since when and it seems that focus on nvk (new open source driver) is going to be on vulkan
- android since version 7 - Eighty-five percent of active Android devices support Vulkan (this is better than android Version Rollout) https://developer.android.com/games/develop/use-vulkan
- rpi, not sure which versions
Probably all of them have better Vulkan than opengl drivers (due to drivers being simpler). David Arlie rather quickly implemented first Vulkan driver for AMD once Vulkan was first released. Just in case you need incentive.
I was thinking of starting something similar as a learning exercise, but I’m really limited in time and not skilled as much in c++, so it would probably lead nowhere. Now I can just build on top - if I get any time for this, will come probably with questions.
Anyway, this idea was to make something modern. Without the legacy crap. Actual goals were:
- Vulkan only (move gfx API Info the future)
- no x/xwayland (most of the apps in newer toolkits already support Wayland, the others I’d rather avoid)
- Multithreaded
Interesting, I don’t recall where I read about Vulkan support still being experimental in many Mesa drivers; it might have been an outdated post. I’ll look into it, and perhaps I’ll decide to dive into learning Vulkan. Additionally, there are buffer-sharing mechanisms that already work smoothly with GLES, so I need to explore if the situation is similar for Vulkan. Thanks for your response, and if you have the time and inclination to help include it, feel free to do so! 😄
What does “Single, Double or Triple Buffering” mean?
The idea of single, double, and triple buffering revolves around how many framebuffers we use for display rendering. Typically, we go with double buffering, displaying one framebuffer while rendering happens on the other. Swap them, and the cycle continues. The goal is to prevent screen tearing and glitches from popping up on the screen.
Lets see if I got this right, you (the OP), the creator of Louvre, managed to create an example compositor that looks like a better desktop experience than the entire KDE and GNOME teams could ever develop with their infinite wisdom and funding? Fucking amazing. :)
I know this is an example, but seriously following the “copy apple down to the last pixel” approach you should consider creating a DE for Linux that doesn’t have themes or any user tweaks, just a simple and pixel-perfect copy of macOS. The problem with GNOME and KDE is that they both fail in simple design principals such as proportions, item spacing and whatnot while Apple, and you by extension, excels in that aspect.
Furthermore my personal opinion is that GNOME tries to reinvent everything and ends up fucking things up and creating situations like the lack of desktop icons going into the activities view by default etc. KDE however does some other stuff right but they fail really badly in terms of proportions and item spacing. Their taskbar is also a shame, for a group that says they want to copy Windows’ style they aren’t doing that well.
Desktop experiences when it comes to design peaked with macOS Monterey (after that Apple did changes to the settings that are still not polished) and in terms of usability they peaked with the release of Exposé, Spaces and later their integration on Mission Control (initially bad but now they seem better).
If you do create a 1:1 copy of macOS desktop experience (and keep it updates) as a new DE you’ll most likely become very popular in no time. It doesn’t need themes, customization and all the personalization that would make it really hard to create, just a simply pixel perfect copy of macOS.
Thanks! While I may have nailed server-side decorations in that example, as you know, there is too much other stuff to take into account to make a DE actually functional. So, I respect a lot what KDE and GNOME do and the innovations they make. I actually want to create a macOS clone, hahaha. That is one of the reasons I started this project. I will soon continue working on a library for exposing global menus in Wayland/X11. Qt allows defining a custom platform plugin, enabling us to plug external systems for managing global menus. Sadly, I think GTK4 no longer supports that, so I believe an approach would be to display a standard menu with basic functions for apps that don’t support it.
I actually want to create a macOS clone, hahaha. That is one of the reasons I started this project.
Well it seems I’m not the only one then :P
