Decided to try writing a Wayland compositor for fun.
-
on niri-git, the nautilus rename popup now works properly with IMEs running
(and generally popups with text fields should work now)
Experimenting with a restructure of the niri rendering code to uncurse it somewhat by getting rid of all complex impl Iterator chains and lifetimes, which also lets me remove some intermediate small Vecs. In essence, going from pull to push iteration.
I'm surprised that the result is consistently 2-3x faster than before. Wonder if it's the Vecs, or if inverting (massive) codegen'd iterators into a normal call stack passing a closure arg, providing the main benefit
-
Experimenting with a restructure of the niri rendering code to uncurse it somewhat by getting rid of all complex impl Iterator chains and lifetimes, which also lets me remove some intermediate small Vecs. In essence, going from pull to push iteration.
I'm surprised that the result is consistently 2-3x faster than before. Wonder if it's the Vecs, or if inverting (massive) codegen'd iterators into a normal call stack passing a closure arg, providing the main benefit
Finished the push-based rendering refactor, made a write-up here for the curious: https://github.com/YaLTeR/niri/pull/3113
It even ended up with a negative delta (+762 -780) which is always a W.
Btw I ran the comparison on my Eee PC and there the difference is even more extreme, like 8x faster rendering list construction (which is once again only a part of the total rendering time, and notably doesn't include actual rendering, but still nice).
-
Finished the push-based rendering refactor, made a write-up here for the curious: https://github.com/YaLTeR/niri/pull/3113
It even ended up with a negative delta (+762 -780) which is always a W.
Btw I ran the comparison on my Eee PC and there the difference is even more extreme, like 8x faster rendering list construction (which is once again only a part of the total rendering time, and notably doesn't include actual rendering, but still nice).
biblically accurate window management
-
biblically accurate window management
i'm reviving the PR integrating Tracy GPU profiling into Smithay. Here are two test captures from niri: one for normal + screencast rendering, one for iGPU + dGPU monitor rendering
-
i'm reviving the PR integrating Tracy GPU profiling into Smithay. Here are two test captures from niri: one for normal + screencast rendering, one for iGPU + dGPU monitor rendering
Looking for ideas on how to go about translating niri (the binary, and the wiki). If you have experience doing this with other FOSS projects, please share:
-
Looking for ideas on how to go about translating niri (the binary, and the wiki). If you have experience doing this with other FOSS projects, please share:
Is there any good way of moving a process into a systemd StartTransientScope together with its children?
In niri we put spawned processes into scopes, so oomd and other stuff can work properly. Usually you do it by putting yourself into a scope, then exec-ing the target program. But that's a 7 ms toll on startup time, so in niri we spawn the program right away, and then put it into a scope. However, if the program forks fast enough, that child doesn't go into the scope..
-
Is there any good way of moving a process into a systemd StartTransientScope together with its children?
In niri we put spawned processes into scopes, so oomd and other stuff can work properly. Usually you do it by putting yourself into a scope, then exec-ing the target program. But that's a 7 ms toll on startup time, so in niri we spawn the program right away, and then put it into a scope. However, if the program forks fast enough, that child doesn't go into the scope..
Turns out GNOME Shell has the same problem: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
I also wrote it down in a more detailed form on the niri issues for future reference: https://github.com/YaLTeR/niri/issues/3201
-
Turns out GNOME Shell has the same problem: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
I also wrote it down in a more detailed form on the niri issues for future reference: https://github.com/YaLTeR/niri/issues/3201
niri can now include the mouse pointer on window screenshots, a feature that had several more edge cases than I thought before starting to work on it (and it's likely not the ones you think, those ones were easy)
-
niri can now include the mouse pointer on window screenshots, a feature that had several more edge cases than I thought before starting to work on it (and it's likely not the ones you think, those ones were easy)
Merged another long time overdue niri PR: mouse cursor via metadata in PipeWire screencasts (lets you toggle Show Cursor on/off in OBS), and full mouse cursor support in window casts.
The cursor is visible only when the window is receiving mouse events—if you're moving the mouse on top of something else covering the target window, the cursor won't be (unintentionally) painted.
Thanks @abmantis for driving this, including debugging a memory bug in PW!
-
Merged another long time overdue niri PR: mouse cursor via metadata in PipeWire screencasts (lets you toggle Show Cursor on/off in OBS), and full mouse cursor support in window casts.
The cursor is visible only when the window is receiving mouse events—if you're moving the mouse on top of something else covering the target window, the cursor won't be (unintentionally) painted.
Thanks @abmantis for driving this, including debugging a memory bug in PW!
Working on a screencast IPC for niri. The idea is to give info to desktop bars to be able to add a screencast indicator whenever something is recording the screen.
Got it hooked up for both PipeWire (obviously) and wlr-screencopy. For the latter there's no good way to tell if something is a screencast so I went with some heuristics.
Here's the icon working on the DMS bar, as well as a popup with the full available info I made for debugging.
-
Working on a screencast IPC for niri. The idea is to give info to desktop bars to be able to add a screencast indicator whenever something is recording the screen.
Got it hooked up for both PipeWire (obviously) and wlr-screencopy. For the latter there's no good way to tell if something is a screencast so I went with some heuristics.
Here's the icon working on the DMS bar, as well as a popup with the full available info I made for debugging.
Oh right, for PipeWire I can send the node ID, which DMS can then use to fetch the consumer application name!
-
Oh right, for PipeWire I can send the node ID, which DMS can then use to fetch the consumer application name!
The screencast IPC is now merged: https://yalter.github.io/niri/niri_ipc/struct.Cast.html
-
The screencast IPC is now merged: https://yalter.github.io/niri/niri_ipc/struct.Cast.html
Also added niri msg action stop-cast to force-stop a PipeWire screencast
-
Also added niri msg action stop-cast to force-stop a PipeWire screencast
working on my new visual style
-
working on my new visual style
So yeah, I'm working on blur for niri. I'm doing "xray blur" first where the idea is that you only include background surfaces, so you pretty much never have to redo the blur—next to zero perf impact unless you have a video wallpaper or smth.
Turns out that it's quite tricky to do well, especially with our Overview. I'm like on my third refactor attempt now but I think I've got a good approach.
During this video there's no reblurring whatsoever, all just drawing cached static textures.
-
So yeah, I'm working on blur for niri. I'm doing "xray blur" first where the idea is that you only include background surfaces, so you pretty much never have to redo the blur—next to zero perf impact unless you have a video wallpaper or smth.
Turns out that it's quite tricky to do well, especially with our Overview. I'm like on my third refactor attempt now but I think I've got a good approach.
During this video there's no reblurring whatsoever, all just drawing cached static textures.
Added non-xray blur, based on @drakulix's Smithay/COSMIC implementation.
Keep in mind this blur work is still extremely WIP and with many issues (some visible on the video). It's also still not entirely clear to me how to best structure the code around it in niri. We'll see
-
Alright, getting somewhere! I think I've figured out a good code structure for the xray blur. It now correctly works even inside offscreens (opening animation, and when you drag a window targeting the tiling layout), and it should also work properly with the upcoming screen magnifier (that we have in pull requests).
Still not a single blur re-render in this entire video!
-
Alright, getting somewhere! I think I've figured out a good code structure for the xray blur. It now correctly works even inside offscreens (opening animation, and when you drag a window targeting the tiling layout), and it should also work properly with the upcoming screen magnifier (that we have in pull requests).
Still not a single blur re-render in this entire video!
you know it's serious when you have to pull out a notebook to figure out the coordinate transforms
-
you know it's serious when you have to pull out a notebook to figure out the coordinate transforms
Today, got xray working on the closing window animations. The reason this needs special treatment is that when a window closes, niri renders a snapshot of its last visible contents to use for the animation. This happens outside the normal rendering path so I needed to thread through the xray background rendering logic as well as the correct window coordinates (since the xray background needs to know where the window is to draw the correct thing).
-
Today, got xray working on the closing window animations. The reason this needs special treatment is that when a window closes, niri renders a snapshot of its last visible contents to use for the animation. This happens outside the normal rendering path so I needed to thread through the xray background rendering logic as well as the correct window coordinates (since the xray background needs to know where the window is to draw the correct thing).
Today: implemented (a limited but useful subset of) both ext-background-effect and org-kde-kwin-blur protocols. Clients use these to request blur on their surfaces without having to configure anything in the compositor. These protocols also allow clients to blur only parts of their surfaces, for example here excluding client-side decoration bars and shadows.
Here are three terminals all with their org-kde-kwin-blur setting enabled.
