Decided to try writing a Wayland compositor for fun.
-
I'm quite enjoying playing with the Tracy profiler. Turns out when you run the program with sudo, it records a ton of extra useful info, like CPU core scheduling, monitor VSync events, kernel context switches, what your process is blocked on.
I also annotated my compositor with Tracy Frame events for monitor VBlank cycles. I can then set a target FPS in Tracy and instantly see which frames were too slow! Both in the bar at the top, and in the main area highlighted in red.
lol a few days ago someone posted niri on the orange site and now it surpassed all my other projects by star count 🫠
-
lol a few days ago someone posted niri on the orange site and now it surpassed all my other projects by star count 🫠
aaaaaaaaahhhhhhhhhhh these two days were a grind but I somehow got monitor streaming working! with pipewire and dmabufs and dbus and screencast portal and everything! and it wooorkssssssssss woooooooooooooo
-
aaaaaaaaahhhhhhhhhhh these two days were a grind but I somehow got monitor streaming working! with pipewire and dmabufs and dbus and screencast portal and everything! and it wooorkssssssssss woooooooooooooo
I just streamed for an hour from this and nothing crashed??
-
I just streamed for an hour from this and nothing crashed??
Dmabuf screencasting is crazy good. Here's a histogram of the screencasting overhead on my 2560×1600@165 screen—the median is 300 microseconds, and the worst across 12,669 frames was just below 1 ms. Most of that time is spent rendering the frame, perhaps something could even be further optimized in Smithay.
And yeah, if you look at the profiling timeline, I zoomed it in such a way that almost the entire width is taken by one frame, that is 6.05 ms long. Most of it is completely empty!
-
Dmabuf screencasting is crazy good. Here's a histogram of the screencasting overhead on my 2560×1600@165 screen—the median is 300 microseconds, and the worst across 12,669 frames was just below 1 ms. Most of that time is spent rendering the frame, perhaps something could even be further optimized in Smithay.
And yeah, if you look at the profiling timeline, I zoomed it in such a way that almost the entire width is taken by one frame, that is 6.05 ms long. Most of it is completely empty!
Today in Wayland compositor profiling! Turns out closing a shm pool file descriptor can result in a fat stall of up to like 6 ms with the kernel waiting on some spinlocks. Which is extra fun when you realize it covers the entire frame budget of your 165 Hz screen, and some clients are sometimes doing it every frame!
I'm trying a "dropping thread" workaround where the fd closing happens on a separate thread. Appears to work at the first glance.
-
Today in Wayland compositor profiling! Turns out closing a shm pool file descriptor can result in a fat stall of up to like 6 ms with the kernel waiting on some spinlocks. Which is extra fun when you realize it covers the entire frame budget of your 165 Hz screen, and some clients are sometimes doing it every frame!
I'm trying a "dropping thread" workaround where the fd closing happens on a separate thread. Appears to work at the first glance.
new main loop stall dropped
and it is, uhhhhh, epoll_wait doing blocking disk decryption for solid 8 ms? is that a thing that it does?
seems to have happened once over a long period but still
-
new main loop stall dropped
and it is, uhhhhh, epoll_wait doing blocking disk decryption for solid 8 ms? is that a thing that it does?
seems to have happened once over a long period but still
Found the same disc decryption during rendering. Does it just randomly decide to do it or something?
-
Found the same disc decryption during rendering. Does it just randomly decide to do it or something?
Aside from this and some other weirdness, not a single dropped frame on my slower laptop! (which is admittedly just 60 Hz)
-
Aside from this and some other weirdness, not a single dropped frame on my slower laptop! (which is admittedly just 60 Hz)
Thought of another thing to plot in Tracy: target presentation time offset! This is the difference between when a frame was shown on screen and the target time that we were rendering for.
Here you can see data across 17 seconds of runtime while recording with OBS. Offset on both monitors fluctuates within a few microseconds around zero, which means that our rendering lands right on time.
-
Thought of another thing to plot in Tracy: target presentation time offset! This is the difference between when a frame was shown on screen and the target time that we were rendering for.
Here you can see data across 17 seconds of runtime while recording with OBS. Offset on both monitors fluctuates within a few microseconds around zero, which means that our rendering lands right on time.
It's also common to see one frame worth of offset like on this zoomed-out screenshot. This happens when the compositor wakes up from idling too late into the monitor refresh cycle and doesn't manage to render a new frame in time.
-
It's also common to see one frame worth of offset like on this zoomed-out screenshot. This happens when the compositor wakes up from idling too late into the monitor refresh cycle and doesn't manage to render a new frame in time.
I'm still working on niri btw (and using it myself too). Today I finally finished a window layout refactor that was due from very early on.
Now the layout always works correctly, with all the paddings, struts, fullscreen windows and animations. It's tricky because while most of the logic operates only on the "working area" (view excluding struts), fullscreen windows in particular must cover the entire view area, while otherwise acting as just another regular window column.
-
I'm still working on niri btw (and using it myself too). Today I finally finished a window layout refactor that was due from very early on.
Now the layout always works correctly, with all the paddings, struts, fullscreen windows and animations. It's tricky because while most of the logic operates only on the "working area" (view excluding struts), fullscreen windows in particular must cover the entire view area, while otherwise acting as just another regular window column.
niri development is ongoing, getting a lot of help from kchibisov too.
Today I implemented an interactive area screenshot capture tool. Almost like a mini screenshot UI
-
niri development is ongoing, getting a lot of help from kchibisov too.
Today I implemented an interactive area screenshot capture tool. Almost like a mini screenshot UI
Decided to make a new demo video for niri, finally. The last one was so old that niri didn't even have cursors implemented, it showed an orange rectangle instead. 🫠
Here's the link again for the curious: https://github.com/YaLTeR/niri
Very happy I've come this far writing my own compositor from scratch. Honestly thought my motivation would only last for two weeks max, but here we are.
Learned a ton in the process, and now this experience helps me with Mutter & Shell profiling.
-
Decided to make a new demo video for niri, finally. The last one was so old that niri didn't even have cursors implemented, it showed an orange rectangle instead. 🫠
Here's the link again for the curious: https://github.com/YaLTeR/niri
Very happy I've come this far writing my own compositor from scratch. Honestly thought my motivation would only last for two weeks max, but here we are.
Learned a ton in the process, and now this experience helps me with Mutter & Shell profiling.
The development pace had slowed down a little, so I've tagged an alpha release for niri: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-alpha.1
Also made a COPR for the occasion, if you're on Fedora: https://copr.fedorainfracloud.org/coprs/yalter/niri/
-
The development pace had slowed down a little, so I've tagged an alpha release for niri: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-alpha.1
Also made a COPR for the occasion, if you're on Fedora: https://copr.fedorainfracloud.org/coprs/yalter/niri/
A month has passed and a number of important additions have landed in niri, so here's a second alpha release: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-alpha.2
Highlights include relative-pointer and pointer-constraints which let Xwayland masterfully handle 3D games mouse look, and popup unconstraining which prevents popups from opening off-screen. I actually made popups place within their window with some padding, which looks quite nice.
-
A month has passed and a number of important additions have landed in niri, so here's a second alpha release: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-alpha.2
Highlights include relative-pointer and pointer-constraints which let Xwayland masterfully handle 3D games mouse look, and popup unconstraining which prevents popups from opening off-screen. I actually made popups place within their window with some padding, which looks quite nice.
Aaahhhhhh another difficult refactor down and niri now does multi-GPU! By which I mean that monitors plugged into secondary GPUs will now light up and work. All the screenshot UI and screencast portal stuff also works just fine. Wouldn't be able to do this as quickly without Smithay's MultiRenderer support and lots of help from @drakulix
I went for the easier strat of always rendering on the primary GPU, but you can also pick render GPU dynamically, which apparently cosmic-comp does, cool!
-
Aaahhhhhh another difficult refactor down and niri now does multi-GPU! By which I mean that monitors plugged into secondary GPUs will now light up and work. All the screenshot UI and screencast portal stuff also works just fine. Wouldn't be able to do this as quickly without Smithay's MultiRenderer support and lots of help from @drakulix
I went for the easier strat of always rendering on the primary GPU, but you can also pick render GPU dynamically, which apparently cosmic-comp does, cool!
Tagged niri v0.1.0-alpha.3 with multi-GPU support, borders and other improvements! Multi-GPU was one of the bigger things I wanted to get done before going out of alpha so I guess I'm slowly getting there.
-
Tagged niri v0.1.0-alpha.3 with multi-GPU support, borders and other improvements! Multi-GPU was one of the bigger things I wanted to get done before going out of alpha so I guess I'm slowly getting there.
Turns out that if you implement xdg-decoration in your compositor but tell clients that you want CSD, then SDL2 + libdecor clients will break due to a bug. The bug is already fixed, but the fix hasn't made it to any SDL2 release yet, let alone all the runtimes and vendored copies.
Hiding xdg-decoration from clients it is then
-
Turns out that if you implement xdg-decoration in your compositor but tell clients that you want CSD, then SDL2 + libdecor clients will break due to a bug. The bug is already fixed, but the fix hasn't made it to any SDL2 release yet, let alone all the runtimes and vendored copies.
Hiding xdg-decoration from clients it is then
I added text rendering to niri using pangocairo, which turned out to be surprisingly simple. It basically "just worked". This unlocks a lot of features, beginning with a hotkey overlay, which should help people get started (suggested by @ju).
I've tagged niri 0.1.0-beta.1 which includes the overlay along with many more improvements: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-beta.1
I'm now happy enough with the feature set so in a week I'll release 0.1.0. Time to finally catch up on other projects I've been neglecting.
-
I added text rendering to niri using pangocairo, which turned out to be surprisingly simple. It basically "just worked". This unlocks a lot of features, beginning with a hotkey overlay, which should help people get started (suggested by @ju).
I've tagged niri 0.1.0-beta.1 which includes the overlay along with many more improvements: https://github.com/YaLTeR/niri/releases/tag/v0.1.0-beta.1
I'm now happy enough with the feature set so in a week I'll release 0.1.0. Time to finally catch up on other projects I've been neglecting.
I'm pretty excited to finally be able to "release" niri soon but god I'm glad I set aside a beta week for bugfixes. We already stumbled upon and fixed several issues
