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.
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!
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
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)
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.
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
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/
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!
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
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
A few latency tests before release confirm that niri's still doing good (at least on idle; I don't have any repaint scheduling yet but on idle it doesn't matter). The compositors are pretty much within the noise threshold from each other. Except some sway fullscreen bug and Shell losing one frame somewhere.
Well, I'm happy to release the first stable version of niri, my scrollable-tiling compositor: https://github.com/YaLTeR/niri/releases/tag/v0.1.0
Very satisfied with the current state, even though there's plenty left to do. Took a lot of time and work but I've certainly learned a lot, and I'm glad to have contributed a bit to Smithay too!
Before adding more animations into niri, I'm making a "visual tests" application. It shows a set of hardcoded scenarios which I can quickly go through and visually check that everything looks right.
It uses solid color rectangles as "windows", but otherwise this is the real niri layout code and real niri + Smithay rendering code, drawing to a GTK GL area.
For example, on the last test you can see that my offscreen code currently clips CSD shadows (during the open animation).
visual tests are such a lifesaver, so glad I stole that idea from osu!lazer
The window opening animation is now live as part of niri v0.1.2: https://github.com/YaLTeR/niri/releases/tag/v0.1.2
I'm really looking forward to more animations, but wow they sure do need a lot of care to get right in all the edge cases.
Also, I added a way to programmatically invoke compositor actions, and turns out that's quite useful for making video demos!
For a bit of fun I added gradient borders to niri. One of the visual tests for it turned out a bit mesmerizing to look at
Tagged niri v0.1.3: https://github.com/YaLTeR/niri/releases/tag/v0.1.3
This one has much improved touchpad gestures with inertia, springs, rubberbanding and everything else I copied from libadwaita, my primary source for things that feel good 
Also thanks @alice for helping and giving feedback on the gestures and for giving a try to the touch support!
Just implemented something I've had in mind for a while: compositor-side blocking out of windows from screencasts! The compositor is the perfect place to do this since it can replace the window contents in the render tree, which will work fine with any kind of overlapping, transparency, etc. AND it will work with anything that records the screen through the portal, be it OBS or video meeting, or whatever.
There's actually an important edge case here: if you open the screenshot UI while recording the monitor, then the screenshot UI preview will show the window, and OBS, recording the screenshot UI preview, will hence also show the window. There are trade-offs here for how you want this to work; for now I put a big warning around the option, and added a stricter mode that blocks out the window from ANY screen capture (which means you can't screenshot it).
I think for the built-in screenshot UI this is solvable with one more layer of indirection (render the screenshot UI preview itself twice, once for screencasts, and once for the monitor). However, for third-party screenshot annotation tools, this will still be a problem.
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
@YaLTeR
This is very interesting, I really do like the idea of visual cues and just enough animations to communicate what is happening. I daily drive sway, and have had a watchful interest in hyprland for this reason, I do think there are a lot of ways this tech could innovate like having existing layouts with dead space blocks until filled with a new window, and resizing the parent container to not use 100% of the screen similar to 0:50
By the way what is the name of the paint app on the left? I'm not sure I've seen it before.
@lorendias @CleoMenezesJr yeah, definitely some interesting underexplored ideas left.
The app is Rnote and it's very good: https://flathub.org/apps/com.github.flxzt.rnote
@YaLTeR OH HEY I HAD THIS IDEA LIKE 5 YEARS AGO
well there goes a project I had in mind (don’t worry tho, I evolved and perfected my ideas!)
@xerz heh, well, it's by no means an original idea—niri is rather directly inspired by PaperWM which I stumbled upon earlier this year and really liked.
@YaLTeR true, I’ve seen it mentioned once or twice — originality is overrated anyway 
@YaLTeR wow this looks really awesome! Such a cool demo too
@a1ba gnome shell is mutter + some overhead, it's useful to see what raw mutter is as the "best possible" result for gnome shell. In this case there's clearly some bug in shell that adds a frame of latency.
@a1ba yeah, you can just run mutter on its own. It's very barebones though, intended mostly for testing
@YaLTeR looks great!
@YaLTeR@mastodon.online this is pretty rad
always fan of window managers that have some different ways of doing things, and 'windows are offscreen but not on a different workspace' seems like an underused concept
@YaLTeR this looks pretty awesome! I’ve been struggling to understand how the desktop portal stuff works so will be sure to give the code a read too.
@vladimir_lu Thanks! Well, in case of xdg-desktop-portal-gnome for screencasting, which I'm using here, I essentially need to provide a few dbus interfaces that look like Mutter's or Shell's, since that's what xdp-gnome is poking. Other portal impls have different requirements, i.e. xdp-wlr will need some wlroots Wayland protocols.
@YaLTeR congrats Ivan! Quite an impressive piece of software you've created here.
@ju thank you and thanks for testing and giving feedback earlier!
@YaLTeR I might even switch to it completely eventually with all the niceties you are putting into this :D
It's great how easy I can switch between GNOME shell and niri.
@YaLTeR No way arch with hyprland
@YaLTeR
In GNOME this could look something like this (see quick mock-up).
@Scott_Trakker yeah, well, PaperWM already does it in GNOME :)
@YaLTeR
Thanks!!
I just installed PaperWM and it almost works as I would like it to work.
Instead of multiple workspaces, I would like to have just one big horizontal workspace, and only one window should be shown on the screen at a time (unless explicitly grouped).
In PaperWM the windows are shown beneath each other in the overview mode. They should stay horizontal.
Is PaperWM still in active development? If so, I will open a bug report for above issues.
@Scott_Trakker yeah, Paper is in active development. Not by me though; I'm listed as a contributor but I only ever opened issues and gave feedback on some design discussions :)
@YaLTeR
And last: by scrolling over the top bar you should be able to scroll between the horizontal windows.
@YaLTeR
Looks very nice!
@YaLTeR just found this and it is a revelation. Fantastic, thank you. Finally a tiling system that makes sense on a small screen @thelinuxEXP
@YaLTeR how would you know what to block ? config, or some protocol and client says "i wanna be hidden pls" ?
@SRAZKVT manually configured window rules. There's no protocol for this unfortunately. Would be kinda cool, but also it's pretty subjective what you want to block (i.e. you don't want to block the password manager when recording a video tutorial on how to use it!)
@YaLTeR id rather some config for disabling blocking, if you need sensitive windows not blocked, then you probably know how to unblock it tbh
@SRAZKVT in niri you can make exclude window rules rather than include, so if such a protocol existed, it would be trivial to do unblocking like this.
@SRAZKVT a wayland protocol would actually be great because it could make the sensitive state double-buffered. Right now if you try to match by window title, you will get 1 frame off results because window title isn't double-buffered, so it's not synchronized with the actual window contents.
@YaLTeR if there's not alr such a protocol or one being worked on, how hard is it to make a new one
@SRAZKVT writing the protocol xml isn't that hard; but you need to get people to care for anything to happen
