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
• 💬 Contact
• 🌟 Projects Using Louvre

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)
• VSync Control
• Gamma Correction
• Screencasting (compatible with PipeWire via xdg-desktop-portal-wlr)
• Painter API and Scene System
• Multi-GPU Support
• Multi-Session Support
• Single, Double or Triple Buffering
• Persistent Clipboard
• Rootful XWayland (rootless mode is not yet supported)

• Wayland
• XDG Shell
• XDG Decoration
• XDG Output
• Presentation Time
• Linux DMA-Buf
• Viewporter
• Fractional Scale
• Tearing Control
• Session Lock
• Wlr Gamma Control
• Wlr Layer Shell
• Wlr Screen Copy
• Wlr Foreign Toplevel Management
• Pointer Gestures
• Pointer Constraints
• Relative Pointer

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.

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 (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.

• Direct Buffer Scanout
• DRM Planes Control
• Rootless XWayland
• DRM Lease Protocol
• Tablet Events Protocol
• Single Pixel Buffer Protocol
• XDG activation Protocol
• Content Type Hint Protocol
• Idle Notify Protocol
• Cursor Shape Protocol
• Virtual Keyboard Protocol
• Input Methods Protocol