send frame callbacks for active screencast windows #642
Conversation
sodiboo
force-pushed
the
fix-1hz-screencast
branch
from
75af433 to
26f5c46
Compare
sodiboo
force-pushed
the
fix-1hz-screencast
branch
from
26f5c46 to
37dadf9
Compare
sodiboo
force-pushed
the
fix-1hz-screencast
branch
from
37dadf9 to
2c56c07
Compare
src/niri.rs
Outdated
|
|
||
| // FIXME: when a window is hidden, it should probably still receive frame callbacks | ||
| // and get rendered for screen cast. This is currently | ||
| // unimplemented, but happens to work by chance, since output | ||
| // redrawing is more eager than it should be. |
There was a problem hiding this comment.
So, this comment should not be removed, it still stands. What this PR does is sends frame callbacks to off-screen windows, which makes them commit a new buffer. Which currently makes niri always redraw the output and hence render a new frame for a screencast. However, ideally niri shouldn't redraw the output if the window that committed a new buffer is fully off-screen. I will at some point add that optimization, which will once again stop off-screen windows from rendering for screencasts (or receiving frame callbacks from this PR for that matter), until this is fixed in a different way.
| output, | ||
| frame_callback_time, | ||
| FRAME_CALLBACK_THROTTLE, | ||
| |_, _| Some(output.clone()), |
There was a problem hiding this comment.
I think instead of being a separate function, this cast check should be integrated into send_frame_callbacks() where it should be part of the if current_primary_output.as_ref() != Some(output) check. The stuff in send_frame_callbacks() does throttling to at most one frame callback per output refresh; without it windows will busy-loop frame callbacks (especially so off-screen windows, which is the primary case here).
|
Are there any updates on this? |
|
no |
|
there was review feedback and then I didn't respond and then I kinda forgot. that's the update lol. waiting on me to do literally anything i guess |
|
More like this isn't really a proper fix so it's back to waiting for me to sometime in the future do a proper fix or something |
|
A In my head, a window rule would be easier than keeping track of windows that OBS or any other program is watching, but I've not looked at the code. How many windows could one need to maintain a normal refresh rate offscreen? (Never ask questions like that, ppl take it as a challenge) |
It would require the exact same solution as just fixing this for window screencasts would require |
4 participants
Fixes #539. cc @yuu-fur who originally brought this issue to my attention, he might find this interesting.
I don't really know what i'm doing here. Frame callbacks are confusing. But this looks entirely reasonable to my eyes, and i've tested it on my own system and it seems to work.