No description
- Rust 98.6%
- Python 1.2%
- GLSL 0.2%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
901b11afc6
During resize, a client with _NET_WM_OPAQUE_REGION set will send a flood of changes to this property as the window changes size and the opaque regions move and change size. Profiling shows that processing all of these updates can take 10-15ms, causing missed vblanks. Not only does it take a while to process the flood of updates, fetching the updated property value from the XWayland server can be very slow during this period (I've observed a median of 3ms and P90 of 12ms, with a P99 of 27ms!). My theory is that x11rb's socket processing architecture appears to be working against us here: in this flood of updates during a resize, a lot of other things are also going on: configure requests, configure notify events, etc. This causes x11rb's incoming event processing to back up, and with the property fetch reply far down the queue of events to process, it takes a while for it to get there. Instead, when receiving a PropertyNotify event for _NET_WM_OPAQUE_REGION, simply None-out the stored value and mark it as dirty. In the pre-commit hook, if the value is dirty, re-fetch the property. This avoids several tens of slow property fetches per frame, coalescing it down to one per frame at most. I've also taken pains to avoid holding the mutex on SharedSurfaceState across the XWayland server round-trip; since that call can take several milliseconds when there's a flood of events, a multi-threaded compositor might experience lock contention if it's trying to do anything else with the X11Surface. This doesn't fully fix the problem: the property fetch in the pre-commit handler can still be slow to the tune of several milliseconds (and sometimes worse) during resize. But this change does eliminate most of the missed vblanks and skipped frames. (If x11rb were to expose poll_for_reply(), we could do this in a non-blocking manner, and completely eliminate this issue, but it's a private function.) In normal non-resize situations, the opaque region will change only rarely (if ever), and even when it does, it should presumably be at a time when there isn't a flood of traffic with the XWayland server, so the lazy re-fetch in the pre-commit handler should complete in microseconds. |
||
| .github | ||
| anvil | ||
| benches | ||
| examples | ||
| smallvil | ||
| smithay-drm-extras | ||
| src | ||
| test_clients | ||
| wlcs_anvil | ||
| .gitignore | ||
| .rustfmt.toml | ||
| AI.md | ||
| build.rs | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| clippy.toml | ||
| compile_wlcs.sh | ||
| CONTRIBUTING.md | ||
| DCO.md | ||
| doc_index.html | ||
| GETTING_STARTED.md | ||
| LICENSE.txt | ||
| README.md | ||
| test_gbm_bo_create_with_modifiers2.c | ||
| test_gbm_bo_get_fd_for_plane.c | ||
| typos.toml | ||
A smithy for rusty Wayland compositors
Goals
Smithay aims to provide building blocks to create wayland compositors in Rust. While not being a full-blown compositor, it'll provide objects and interfaces implementing common functionalities that pretty much any compositor will need, in a generic fashion.
It supports the core Wayland protocols, the official protocol extensions, and some external extensions, such as those made by and for wlroots and KDE
Also:
- Documented: Smithay strives to maintain a clear and detailed documentation of its API and its functionalities. Compiled documentations are available on docs.rs for released versions, and here for the master branch.
- Safety: Smithay will target to be safe to use, because Rust.
- Modularity: Smithay is not a framework, and will not be constraining. If there is a part you don't want to use, you should not be forced to use it.
- High-level: You should be able to not have to worry about gory low-level stuff (but Smithay won't stop you if you really want to dive into it).
Getting started
If you want to learn how to build a compositor with Smithay, consider this getting started guide.
Anvil
Smithay as a compositor library has its own sample compositor: anvil.
To get information about it and how you can run it visit anvil README
Other compositors that use Smithay
- Cosmic: Next generation Cosmic desktop environment
- Catacomb: A Wayland Mobile Compositor
- emskin: A nested Wayland compositor for embedding any app inside Emacs
- MagmaWM: A versatile and customizable Wayland Compositor
- Niri: A scrollable-tiling Wayland compositor
- Strata: A cutting-edge, robust and sleek Wayland compositor
- Pinnacle: A WIP Wayland compositor, inspired by AwesomeWM
- Sudbury: Compositor designed for ChromeOS
- wprs: Like xpra, but for Wayland, and written in Rust.
- Local Desktop: An Android app for running GUI Linux via PRoot and Wayland.
- Otto: A gesture-driven stacking compositor.
System Dependencies
(This list can depend on features you enable)
libwaylandlibxkbcommonlibudevlibinputlibgbmlibseatxwayland
Contact us
If you have questions or want to discuss the project with us, our main chatroom is on Matrix: #smithay:matrix.org.
Contributing
General notes on contributing to Smithay can be found here.
Please note that to submit code to Smithay, you have to agree to our Developer Certificate of Origin.
If you are used to using generative AI, please ensure you read our Policy before engaging.