Louvre is a high-performance C++ library designed for building Wayland compositors with a strong emphasis on ease of development.
- 📖 C++ API Documentation
- 🎓 Tutorial
- 🕹️ Examples
- 📦 Downloads
- ⚙️ Environment
- 💬 Contact
- 🌟 Projects Using Louvre
- 🎞️ Watch Video Demo
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.
- Fractional Scaling (with optional oversampling)
- Direct Scanout (primary plane)
- VSync Control
- Gamma Correction
- Screencasting (compatible with PipeWire via xdg-desktop-portal-wlr)
- Painter API and Scene System
- Multi-GPU Support
- Multi-Session Support
- Double and Triple Buffering
- Persistent Clipboard
- Rootful XWayland (rootless mode is not yet supported, however, interesting projects such as Wayland Transpositor, Wayland Proxy Virtwl, and Xwayland Satellite can provide a rootless experience).
- Wayland
- XDG Activation
- XDG Shell
- XDG Decoration
- XDG Output
- Presentation Time
- Linux DMA-Buf
- Single Pixel Buffer
- Viewporter
- Fractional Scale
- Tearing Control
- Session Lock
- Idle Notify
- Idle Inhibit
- Content Type Hint
- Wlr Gamma Control
- Wlr Layer Shell
- Wlr Foreign Toplevel Management
- Wlr Output Management
- Wlr Screen Copy
- Image Capture Source
- Foreign Toplevel List
- Pointer Gestures
- Pointer Constraints
- Relative Pointer
- DRM Lease
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
- Linux DMA-Buf
- DRM/KMS
- Wayland
- Libinput
- Wayland
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.
The benchmark results have not been updated since 2023 and may not accurately reflect the current performance of the tested compositors.
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 (or more). 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.
- Rootless XWayland
- DRM Synchronization Object
- Cursor Shape Protocol
- DRM Overlay Planes Control
- Tablet Events Protocol
- Virtual Keyboard Protocol
- Input Methods Protocol