feat: force render

[busyoGG]

Allows the user to force a window to render even when it is offscreen or being captured by a screencast.

This behavior is controlled by the following window rule:

window-rule {
    // match rule
    force-render true    // not needed if the window is being cast
    force-render-fps 60 // if you need fps limit
}

2025-10-16_19-54-04.mp4

[YaLTeR]

For screencast it should work out of the box; but why would this be needed outside a screencast?

[busyoGG]

For screencast it should work out of the box; but why would this be needed outside a screencast?

For screen recording, it already works out of the box without any configuration.

Sometimes I run turn-based games with an auto-battle feature on another workspace, and if rendering doesn’t happen, the battle logic can’t complete.

[HigherOrderLogic]

Sometimes I run turn-based games with an auto-battle feature on another workspace, and if rendering doesn’t happen, the battle logic can’t complete.

Iirc Yalter said that clients should expect this and handle it properly instead.

[busyoGG]

Sometimes I run turn-based games with an auto-battle feature on another workspace, and if rendering doesn’t happen, the battle logic can’t complete.

Iirc Yalter said that clients should expect this and handle it properly instead.

Hyprland also offers a similar feature.

I think providing a special solution to address this issue is also acceptable.

If you don’t use it, it’s equivalent to not running this logic.

[YaLTeR]

Yeah. That's how it works on GNOME etc

[ykshek]

KDE's equivalent would be the window rule
Block Compositing: Force No

[busyoGG]

KDE's equivalent would be the window ruleKDE Block Compositing: Force No

I don’t think it does the same thing.I just tried it and it doesn't force render the game on another workspace.

[ykshek]

Nevertheless, in some retro games where game/network logic is bound to its fps, it'd be nice to have this window rule.

[kamikaze211]

Oh I really need it lol
I play Honkai Star Rail, it has auto-battle mode, that I can run the game in back ground, but the background window frame limit makes it run very slow, so I have to wait for long time until the battle be completed.
When I use Plasma, there are some ways to resolve it, but I don't know how to do this on Niri.

[phisch]

For screencast it should work out of the box; but why would this be needed outside a screencast?

For screen recording, it already works out of the box without any configuration.

Sometimes I run turn-based games with an auto-battle feature on another workspace, and if rendering doesn’t happen, the battle logic can’t complete.

I have faced the same issue in several games before, and would really appreciate an option like this window rule. Not sure if there is a better solution, but I personally like the window rule approach here.

[ToxicMushroom]

My use case is FfXIV an mmo where you can sit for hours in a party finder and need to hear the game sounds to know when its filled.

But ths game speed is messed up when on another workspace. Leading to missed sounds, jarring bgm, broken autowalk etc

[YaLTeR]

How do they work on gnome, kde, sway?

[alessiorapisarda]

How do they work on gnome, kde, sway?

KDE works the same way as Niri currently, if a window (game) is on another workspace it will render at very low FPS/freeze
If it's hidden behind another windows (single workspace workflow) it will render as normal
In Niri the game won't render not only on another workspace but also if you scroll the window away in the same workspace (game must be fullscreen-maximized)

[ToxicMushroom]

For me with FFXIV on another workspace:
kde - fullspeed
gnome - fullspeed
sway - crawlspeed
niri - crawlspeed

[idoric]

@ToxicMushroom With Niri, have you tried with the window in floating mode? Does it make a difference?

[phisch]

t should work out of the box; but why would this be needed outside a screencast?

I believe this isn't true for windows that are a dynamic screencast target. I just tested this out, and whenever the target of the dynamic screen cast is off-screen, the frames drop significantly.

[YaLTeR]

I believe this isn't true for windows that are a dynamic screencast target. I just tested this out, and whenever the target of the dynamic screen cast is off-screen, the frames drop significantly.

It isn't because it currently doesn't work (for screencasts).

[busyoGG]

Perhaps I should reiterate that this feature for screencasts does not require explicit configuration and it's worked.

The frame rate drop could be due to a graphics card issue,idk.

2025-11-01_16-54-49.mp4

[YaLTeR]

Perhaps I should reiterate that this feature for screencasts does not require explicit configuration.

Yes, that is how it is supposed to work and how this PR already does it. I was just clarifying for @phisch who misinterpreted my previous comment.

[phisch]

Oh, I see. Sorry for misinterpreting! Very happy to see this in niri soon!