Decided to try writing a Wayland compositor for fun. Took me a few days to get things going to a video-able state.
This is scrollable tiling, heavily inspired by PaperWM (which I'm still using and very much enjoying). You've got an infinite strip of windows that you can scroll through.
It's also got dynamic workspaces which work like in GNOME Shell (the Correct™ way to do workspaces), but all monitors have workspaces.
The repo is https://github.com/YaLTeR/niri if you want to peek at the code
Added quite a number of things into the compositor since then. It's at the point where I can somewhat-comfortably use it for working or (Wayland-only) gaming sessions.
Today I figured out how to make it run as a proper session, launched from GDM, with systemd integration and all. It even mostly works!
Also finally implemented the ability to take screenshots—this one is from a real session.
Kinda want to try my hand at the screencast portal for OBS. How hard can it be, right? 🙃
Almost done adding touchpad gesture support to Smithay!
Here you can see the pinch zoom/rotate gesture visually in gtk4-demo, then the swipe gesture only in WAYLAND_DEBUG on the right, then the hold gesture by stopping the kinetic scrolling by putting a finger on the touchpad.
After adding dmabuf feedbacks to niri, I stumbled upon an extremely strange performance problem when using overlay planes. One specific animation, with a GTK 4 window open, stutters, but only when going into one direction.
Spent half a day debugging it with Smithay developers. Couldn't crack it yet; for some reason an AMDGPU kernel worker just... takes a while under those specific conditions, causing delayed frames. Seems to be doing the same thing as in the normal case, just... slower somehow.
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.
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!
Implemented this idea. It means rendering each monitor 3 times always for the screenshot but maybe it's fine? On this laptop 3 monitors × 3 renders takes 2 ms, and there's some unnecessary blocking I forgot to remove.
On the video, note how for me the screenshot UI has Secrets visible, but on the recording afterwards it's always blocked out.
Amidst all the fires being put out, niri 0.1.4 which can block out windows from screencasts! https://github.com/YaLTeR/niri/releases/tag/v0.1.4
And also gamma control, focus follows mouse, warp mouse to focus, wheel and touchpad scroll bindings, xdp-gnome 46 support.
Also, every single config option is now documented on the wiki! Which took like an entire week of work (even though I was reusing a lot of my previously written docs in the config). Check it out here: https://github.com/YaLTeR/niri/wiki/Configuration:-Overview
Took the whole yesterday and a bit of today, but I've got window closing animations working! These turned out to be tricky because they need storing a snapshot of the surface render tree to draw once the app is gone.
Some apps may start destroying their subsurfaces before the main surface, like alacritty with its sctk CSD, making it very easy to miss parts of the window in the snapshot, and therefore in the closing animation.
Also, windows closing to the left no longer shift the view!
Definitely one of the most complex animations yet: window resizing.
Just the crossfade effect itself took a while to get working with all the window geometries and buffer offsets, and then there's the whole multiple window orchestration with Wayland's asynchronous nature. (I don't do animation transactions yet, that'll be a whole other level of complexity on top.)
Happy with the result though, and it's cool that it seamlessly works with block-out-from screencast.
I have this monitor connected through HDMI, and if I enable VRR then it starts modesetting every frame (lol). Guessing some AMDGPU issue.
But today I finally found a DisplayPort → USB C dongle, and this way VRR works perfectly, yay! Even bumped the refresh rate from 144 Hz to 170 Hz, which this monitor supports only through DP.
Anyway, #niri has VRR now
Window movement across columns is now animated too!
These weren't complex per se, but very *finicky*. Spent quite a bit of time chasing down all the offsets and coordinates to add and subtract to avoid jumps, but it seems to all work well now!
All the animations, plus VRR, today in niri 0.1.5: https://github.com/YaLTeR/niri/releases/tag/v0.1.5
I also remade the demo video to showcase the animations and some of the newer features!
@YaLTeR "Destroying a sub-surface takes effect immediately.", see https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subsurface
If a client wants to ensure the content gets destroyed in sync it shouldn't start with destroying a subsurface as compositors may schedule a frame directly after that step. Depending on the architecture, it would be good if the client unmapped (by attaching a NULL buffer) or destroyed the toplevel first (no need to wait for anything after either of these steps).
In rare cases destroying subsurfaces before the main surface could result in a frame where the window is still shown, but decorations got hidden, right before the window itself disappears. Tested...
> please make dialogs and popups float
There's no floating layer yet, I have an issue at https://github.com/YaLTeR/niri/issues/122
> it takes over thirty minutes to compile niri
Uh oh, which system is that?
> please provide precompiled niri bin
Fedora COPR is pre-compiled, there's also an AUR niri-bin package. I can't really provide a distro-independent one.
Ivan Molodetskikh
Alice 
buonhobo
huilong 
twilight
bittin
Paul Richards
dei Muddr
Carlos Echenique
deedend
tpoliaw
Julian Hofer
nano's old account's rotting corpse
TheZoq2
Pyra
Tobias Bernard
kramo
Cleo Menezes Jr. 
Robert Mader
Kat Marchán 🐈