Louvre is a high-performance C++ library designed for building Wayland compositors with a strong emphasis on ease of development.
Creating a Wayland compositor can be a daunting undertaking, often spanning months or even years of dedication. This challenging task involves mastering Linux input and graphic APIs, managing graphic buffers, and meticulously implementing numerous Wayland protocols and their respective interfaces.
Fortunately, Louvre simplifies this intricate process by handling all the complex low-level tasks on your behalf. It even provides a default way for managing protocols, enabling you to have a basic but functional compositor from day one and progressively explore and customize its functionality to precisely match your requirements.
- Rootful XWayland (rootless mode is not yet supported)
- Multi-GPU Support
- Multi-Session Support
- Scene & Views System
- Single, Double or Triple Buffering
- Persistent Clipboard (only for string based mime types)
- Fractional Scaling (since v1.2.0)
- VSync Control (since v1.2.0)
- Gamma Correction (since v1.2.0)
- Wayland
- XDG Shell
- XDG Decoration
- Presentation Time
- Linux DMA-Buf
- Viewporter (since v1.2.0)
- Fractional Scale (since v1.2.0)
- Wlr Gamma Control (since v1.2.0)
- Tearing Control (since v1.2.0)
Within Louvre, you have the flexibility to either employ your own OpenGL ES 2.0 shaders/programs, use the LPainter class for fundamental 2D rendering, or leverage the LScene and LView system, which manages buffer damage and can also handle input events for you. Additionally, it's possible to combine these three approaches as needed.
- Intel (i915 driver)
- AMD (amdgpu driver)
- Nvidia (proprietary and nouveau drivers)
- Mali (lima driver)
- Shared Memory
- Wayland EGL (DMA and GEM flinks)
- Linux DMA-Buf
- DRM/KMS (with the SRM lib)
- X11 (discontinued since version 1.0.0)
- Libinput
- X11 (discontinued since version 1.0.0)
Louvre offers excellent performance. A benchmark consisting of rendering numerous moving wl_subsurfaces (opaque and translucent), in which the louvre-weston-clone example compositor was tested, shows that Louvre can maintain a high FPS rate even in complex scenarios. Furthermore, it uses fewer CPU and GPU resources than popular compositors like Weston and Sway.
| Machine | MacBook Pro A1398 (Retina, 15-inch, Mid 2015) |
| CPU | Intel Core i7-4770HQ @ 2.20GHz (up to 3.4GHz) with 6MB shared L3 cache |
| Memory | 16GB of 1600MHz DDR3L |
| GPU | Intel Iris Pro Graphics - i915 (Intel Graphics) version 1.6.0 (20201103) |
| Display | 15-inch Retina Display with single mode 2880x1800@60Hz |
| OS | Linux Mint 21 - Linux 5.15.0-86-generic |
If you're interested in the details of how the benchmark operates and would like to try it yourself, please refer to this link.
Here is a graph illustrating the benchmark results. It displays the average FPS of each compositor rendering 1 to 50 moving surfaces using double buffering on a HiDPI display.
Most Wayland compositors use a single thread, which drastically slows down their performance when rendering complex scenarios. The reason for this is due to vertical sync, where the compositor must wait a few milliseconds before it can swap the framebuffer it just rendered with the one being displayed on screen. This is done in order to synchronize the swapping with the display refresh rate (vblank) and avoid the tearing effect. When working with a single thread, compositors have "dead times" that prevent them from processing and rendering the content in time for the next frame. That's why they end up skipping a vblank, causing their refresh rate to drop in half. To avoid this problem, Louvre works with multiple threads. Each output (display) renders its content on its own thread, allowing the compositor to continue processing requests and render to other outputs while one is waiting for a vblank. This prevent Louvre compositors from having "dead times" and therefore allows them to maintain a high refresh rate.
The graph on the left displays the raw CPU consumption results, which might suggest that Louvre uses more CPU resources. However, this comparison isn't entirely fair, as Louvre's refresh rate is nearly double that of the others (60 FPS vs 30 FPS avg). When we divide the CPU consumption by the frames per second (FPS), as shown in the graph on the right, it becomes evident that Louvre, in fact, uses fewer CPU resources relative to FPS compared to the other compositors.
Similarly as with CPU consumption, we can observe that Louvre uses fewer GPU resources relative to FPS than the other compositors.
- Touch Events (v2.0.0)
- Pointer Gestures (v2.0.0)
- Relative Pointer (v2.0.0)
- Pointer Constraints (v2.0.0)
- Session Lock (v2.0.0)
- Screencasting (probably v2.0.0)
- Wayland Backend (probably v2.0.0)
- X11 Backend (someday)
- Rootless XWayland (someday)