From 1f7527bbc4d74cbb4d79c7e21e549ef984b36e3a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= Date: Thu, 7 Jul 2022 18:22:33 +0200 Subject: [PATCH] clutter/frame-clock: Fix handling of equal next_presentation_time_us This can happen with the native backend if the previous frame clock dispatch didn't result in any KMS update, e.g. because it was triggered by an input event, but the HW cursor didn't need updating on the stage view. (This is likely to happen on some out of multiple stage views, but might be possible even with a single stage view if the cursor isn't visible) We would previously delay next_presentation_time_us by one refresh interval in this case, which could result in spuriously leaving one refresh cycle unused. Part-of: --- clutter/clutter/clutter-frame-clock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/clutter/clutter/clutter-frame-clock.c b/clutter/clutter/clutter-frame-clock.c index 23141f1c9..ad306225c 100644 --- a/clutter/clutter/clutter-frame-clock.c +++ b/clutter/clutter/clutter-frame-clock.c @@ -527,6 +527,7 @@ calculate_next_update_time_us (ClutterFrameClock *frame_clock, time_since_last_next_presentation_time_us = next_presentation_time_us - last_next_presentation_time_us; if (frame_clock->is_next_presentation_time_valid && + time_since_last_next_presentation_time_us > 0 && time_since_last_next_presentation_time_us < (refresh_interval_us / 2)) { next_presentation_time_us =