-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
output: Really fix max render time #4772
output: Really fix max render time #4772
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't say for sure if this is correct because I don't know how exactly frame_pending
works, but I can give it a go once this is fixed and see if everything works as expected.
Repaint scheduling delays output render and frame done events from output frame events, and block idle frame events from being scheduled in between output frame done and output render in this period of time. If a surface is committed after its frame done event, but before output render, idle frame requests will be blocked, and the surface relies on the upcoming render to schedule a frame. If when the repaint timer expires, output render is deemed unnecessary, no frame will be scheduled. This can lead to surfaces never having their frame callbacks fire. To fix this, we store that a surface has requested a frame in surface_needs_frame. When the repaint expires, if no render is deemed necessary, we check this flag and schedule an idle frame. Fixes swaywm#4768
1d92fcf
to
ed75aa7
Compare
Feel free to give it a go.
|
Seems to be working pretty well in limited testing with output max_render_time of 3ms and view max_render_time of 2ms (Radeon Vega VII, Mesa 20-git). Any finer than that and glxgears which I've been using to test and my browser start dropping frames. Latency feels significantly improved. |
Yeah, looks like this is working well on my tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
This reverts commit cbb2781. In [1], we found issues with block_idle_frame and replaced it with frame_pending. block_idle_frame is now unused. [1]: swaywm/sway#4772
The previous fix (#4766) was discovered to just treat a symptom rather than the cause, and did not account for proper use of per-view max_render_time.
This PR restores the original behavior of view max_render_time, and instead ensures that surface commits always result in a frame being scheduled, even if it occurred during our frame schedule block.