Optional “background rendering” switch to keep frame-callbacks for hidden workspaces

[ergolyam]

Motivation

Currently, when surfaces (windows) are completely hidden or on inactive workspaces, niri stops sending wl_surface.frame callbacks. This behavior saves power, but negatively affects apps like games, video playback (YouTube), and real-time monitoring tools. They respond by significantly lowering FPS, reducing streaming quality, or pausing updates altogether.

Proposal

Introduce an optional configuration to keep sending frame callbacks even if a surface isn't visible. Example configuration:

window-rule {
  match app-id=r#"firefox$"#
  background_rendering "always"
}

Possible modes:

• auto (current behavior)
• always (always send callbacks)
• minimal (limited callbacks, e.g., 1 per second)

Benefits

• Prevents video quality drops in background tabs (YouTube, Twitch).
• Allows games to maintain FPS for streaming (Steam Remote Play, OBS).
• Supports continuous real-time dashboard updates.

Potential drawbacks

• Higher resource usage (mitigated by being opt-in).

Examples in other compositors

• Hyprland: always sends frame callbacks regardless of visibility.
• GNOME/KDE: allow workarounds or optional toggles via extensions/settings.

Conclusion

This optional feature would enhance usability for power users and gamers without negatively impacting default performance.

[YaLTeR]

I mean, that's the entire point, not asking programs to draw a frame when they're invisible. Niri already keeps sending frame callbacks once a second to invisible windows to unbreak the very few clients that have problems with this (notably games).

For window streaming specifically where the window is visible (on the stream), it is a known problem and there's an open issue about it.

For videos you may want pinned windows instead (also an open issue).

If you have problems with something else let's discuss it case by case and figure out if maybe it is a bug in those applications.

Either way, an option like this is the same implementation wise to the aforementioned window streaming case (which is not implemented yet because it's a bit tricky).

This optional feature would enhance usability for power users and gamers

"Power user" is a very catch-all statement suitable for requesting any pet feature whatsoever. Pretty much all niri users are arguably power users, and their usability has not thus far been impacted.

[ergolyam]

The only thing that’s really bugging me right now is Firefox.

If the Firefox window sits on a workspace that isn’t showing, YouTube/Twitch drops from 1080 p to 360 p (sometimes it even pauses buffering).

Leaving even a 1-pixel sliver of the window visible keeps everything fine, so it seems tied to the frame-callback pause rather than the network.

[YaLTeR]

I wonder if it happens in chromium?

[ergolyam]

I wonder if it happens in chromium?

Hi, I don't seem to be seeing this problem on chromium.

[xuc1995]

I mean, that's the entire point, not asking programs to draw a frame when they're invisible. Niri already keeps sending frame callbacks once a second to invisible windows to unbreak the very few clients that have problems with this (notably games).

For window streaming specifically where the window is visible (on the stream), it is a known problem and there's an open issue about it.

For videos you may want pinned windows instead (also an open issue).

If you have problems with something else let's discuss it case by case and figure out if maybe it is a bug in those applications.

Either way, an option like this is the same implementation wise to the aforementioned window streaming case (which is not implemented yet because it's a bit tricky).

This optional feature would enhance usability for power users and gamers

"Power user" is a very catch-all statement suitable for requesting any pet feature whatsoever. Pretty much all niri users are arguably power users, and their usability has not thus far been impacted.

I have encountered a scenario where background "always" refreshing is needed. I am doing Godot game development in the niri environment. I use an external editor to connect to the built-in LSP of the Godot engine for code completion. However, when I expand my code editor to full screen, Godot no longer renders "always," which causes the built-in LSP in Godot to fail to respond in a timely manner.

I think this might be a Godot issue—for instance, the LSP response shouldn't be handled within the rendering callback—but if niri provided "always" rendering, I wouldn't have to worry about this problem. Moreover, in general, there might be other similar scenarios that require such a solution.

[YaLTeR]

That definitely sounds like a Godot bug

[LowByteFox]

I do think something like this would be nice to have, because I wanted to stream today (the day I'm writing this comment) and I have my own virtual avatar model which I wanted to have running on the screen but once I switched back to OBS it was being updated once per second, had to cancel my plan today. Glad I found this discussion because I have no idea what I would've done.

I'll switch back to X11 for now.

[LowByteFox]

After some digging, I have found a solution to my problem! Unfortunately it's not niri specific. So on wlroots based compositors i.e. Sway you can create virtual output using swaymsg create_output, then using wl-mirror you can see what you are doing on the virtual screen, spawn the window there, fullscreen it and then select as screen target using OBS. I have also tested obs-vkcapture which seems to work as well (unlike under Xephyr on X11, which used to crash the program)!

I think it would be neat if niri allowed creating virtual outputs to let users "bypass" the frame per second rendering.

[zeroDivisible]

This is an interesting use case. Overall, I agree with what's said above - once I switched to use niri, I noticed youtube videos played in Firefox to silently drop to 360p, from whatever resolution I had selected. That's happening after some time from me switching from the workspace where firefox is running to the one where it's not.

There are workarounds present which generally revolve around limiting Visibility API - but considering that this needs to be done either through third party or custom extensions, it feels better if it would be supported by Niri.

As I understand, the frame callback suppression in the Wayland spec is a SHOULD, not a MUST so compositors are free to keep sending them. I know that hyprland can be configured to do so, it would be great if niri could too.

[Sempyos]

See: #2609

[zeroDivisible]

Thank you - I wasn't aware of that PR.