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

GitHub - YaLTeR/niri: A scrollable-tiling Wayland compositor.

A scrollable-tiling Wayland compositor. Contribute to YaLTeR/niri development by creating an account on GitHub.

GitHub

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.

Aaand my touchpad gesture support has been merged into Smithay! 

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 🫠
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??

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!

@YaLTeR one day I need to ask you how to make it work on my system again. With mutter tho :3
@alice hmm it doesn't? Maybe you're talking about hardware encoding? Because this is about getting frames from the compositor to OBS, not the subsequent encoding step :)
@YaLTeR I mean if you remember it slows down a lot when obs is just running and not recording anything
@YaLTeR for posterity, I was indeed wrong, it works now. Welp.