brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

clutter/frame-clock: Use vblank_duration in calculate_next_update_time_us

Browse Source 
In this scenario:

1. Only an "empty" content update (which results in no visible output
   change) from client A arrives before the frame deadline, so a frame
   event is sent for that at the deadline.
2. Another "empty" content update from client A results in a frame event
   being scheduled for the next frame deadline.
3. A non-"empty" content update from client B arrives before start of
   vblank, and the resulting output frame manages to hit the next
   display refresh cycle.

The result was that the frame events from steps 1+2 were sent during the
same display refresh cycle, so the frame rate reported by client A was
higher than the display refresh rate.

This change fixes that, at the cost of frame events being sent out
later in the display refresh cycle if there's no new frame for the
next cycle.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3559
Fixes: 8f27ebf87eee ("clutter/frame-clock: Start next update ASAP after idle period")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3878>
This commit is contained in:
Michel Dänzer 2024-07-05 16:14:51 +02:00 committed by Jonas Ådahl
parent aea1aee79e
commit d908984d68
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
clutter/clutter/clutter-frame-clock.c
View File

@ -746,7 +746,7 @@ calculate_next_update_time_us (ClutterFrameClock *frame_clock,
*out_next_update_time_us = next_update_time_us;
*out_next_presentation_time_us = next_presentation_time_us;
*out_next_frame_deadline_us = next_presentation_time_us - min_render_time_allowed_us;
*out_next_frame_deadline_us = next_presentation_time_us - frame_clock->vblank_duration_us;
}
static void