AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-27 06:00:22 +00:00
Code Issues Projects Releases Wiki Activity

frame clock: Better handle non-regular clock cycles

Browse Source 
We try to step the frame clock in whole refresh_interval steps, but to
avoid drift and rounding issues we additionally try to converge it to
be synced to the physical vblank (actually the time we get the
frame-drawn message from the compositor, but these are tied together).

However, the convergence to vsync only really makes sense if the new
frame_time actually is tied to the vsync. It may very well be that
some other kind of event (say a network or mouse event) triggered
the redraw, and not a vsync presentation.

We used to assume that all frames that are close in time (< 4 frames
apart) were regular and thus tied to the vsync, but there is really no
guarantee of that. Even non regular times could be rapid.

This commit changes the code to only do the convergence-to-real-time
if the cause of the clock cycle was a thaw (i.e. last frame drawn and
animating). Paint cycles for any other kind of reason are always
scheduled an integer number of frames after the last cycle that was
caused by a thaw.
This commit is contained in:
Alexander Larsson 2020-06-05 11:30:47 +02:00
parent 82c314f1af
commit 91af8a705b
1 changed files with 8 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
gdk/gdkframeclockidle.c
View File

@ -163,7 +163,7 @@ gdk_frame_clock_idle_dispose (GObject *object)
static gint64
compute_smooth_frame_time (GdkFrameClock *clock,
gint64 new_frame_time,
gboolean new_frame_time_is_regular,
gboolean new_frame_time_is_vsync_related,
gint64 smoothed_frame_time_base,
gint64 frame_interval)
{
@ -205,13 +205,13 @@ compute_smooth_frame_time (GdkFrameClock *clock,
* (current_error/frame_interval)*(current_error/frame_interval)*frame_interval
* But this can be simplified as below.
*
* Note: We only do this correction if we're regularly animating (no
* or low frame skip). If the last frame was a long time ago, or if
* we're not doing this in the frame cycle this call was likely
* triggered by an input event and new_frame_time is essentially
* random and not tied to the presentation time.
* Note: We only do this correction if the new frame is caused by a
* thaw of the frame clock, so that we know the time is actually
* related to the physical vblank. For frameclock cycles triggered
* by other events we always step up in whole frames from the last
* reported time.
*/
if (new_frame_time_is_regular)
if (new_frame_time_is_vsync_related)
{
current_error = new_smoothed_time - new_frame_time;
correction_magnitude = current_error * current_error / frame_interval; /* Note, this is always > 0 due to the square */
@ -412,7 +412,6 @@ gdk_frame_clock_paint_idle (void *data)
{
gint64 frame_interval = FRAME_INTERVAL;
GdkFrameTimings *prev_timings = gdk_frame_clock_get_current_timings (clock);
gint64 old_frame_time = priv->frame_time;
if (prev_timings && prev_timings->refresh_interval)
frame_interval = prev_timings->refresh_interval;
@ -427,11 +426,9 @@ gdk_frame_clock_paint_idle (void *data)
}
else
{
/* For long delays, cycle was probably caused by input event rather than animation */
gboolean is_regular = priv->frame_time - old_frame_time < 4 * FRAME_INTERVAL;
priv->smoothed_frame_time_base =
compute_smooth_frame_time (clock, priv->frame_time,
is_regular,
priv->paint_is_thaw,
priv->smoothed_frame_time_base,
priv->smoothed_frame_time_period);
priv->smoothed_frame_time_period = frame_interval;