Skip to content
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

Merged
merged 3 commits into from
Dec 1, 2019

Conversation

kennylevinsen
Copy link
Member

@kennylevinsen kennylevinsen commented Nov 30, 2019

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.

@emersion emersion added this to the 1.3 milestone Nov 30, 2019
@kennylevinsen kennylevinsen changed the title Really fix max render time output: Really fix max render time Nov 30, 2019
Copy link
Contributor

@YaLTeR YaLTeR left a 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.

sway/desktop/output.c Outdated Show resolved Hide resolved
sway/desktop/output.c Outdated Show resolved Hide resolved
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
@kennylevinsen
Copy link
Member Author

Feel free to give it a go.

frame_pending serves the same purpose as block_idle_frame, stopping wlr_output_schedule_frame from scheduling any idle frames. It is cleared immediately before our frame event, but we can just reset it.

@tokyovigilante
Copy link
Contributor

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.

@YaLTeR
Copy link
Contributor

YaLTeR commented Dec 1, 2019

Yeah, looks like this is working well on my tests.

Copy link
Member

@emersion emersion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@emersion emersion merged commit 275af2a into swaywm:master Dec 1, 2019
emersion added a commit to emersion/wlroots that referenced this pull request Dec 1, 2019
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
ddevault pushed a commit to swaywm/wlroots that referenced this pull request Dec 1, 2019
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
aiqs4 pushed a commit to aiqs4/wlroots that referenced this pull request Dec 19, 2019
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
aiqs4 pushed a commit to aiqs4/wlroots that referenced this pull request Dec 19, 2019
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
aiqs4 pushed a commit to aiqs4/wlroots that referenced this pull request Dec 19, 2019
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
aiqs4 pushed a commit to aiqs4/wlroots that referenced this pull request Dec 19, 2019
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
aiqs4 pushed a commit to aiqs4/wlroots that referenced this pull request Dec 19, 2019
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
filips pushed a commit to filips/wlroots that referenced this pull request Mar 15, 2020
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
@kennylevinsen kennylevinsen deleted the really-fix-max-render-time branch September 22, 2020 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants