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.
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.
The source code of the benchmark can be found in
Louvre/src/benchmark
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.
- Multi-GPU Support
- Multi-Session Support
- Scene & Views System
- Single, Double or Triple Buffering
- Persistent Clipboard (only for string based mime types)
- Wayland
- XDG Shell
- XDG Decoration
- Presentation Time
- Linux DMA-Buf
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-Buff
- DRM/KMS (with the SRM lib)
- X11 (discontinued since version 1.0.0)
- Libinput
- X11 (discontinued since version 1.0.0)
- Touch Events
- Pointer Gestures
- Viewporter
- LView transforms
- LView src rect
- XWayland