[mutter] clutter/frame-clock: Fix handling of equal next_presentation_time_us



commit 1f7527bbc4d74cbb4d79c7e21e549ef984b36e3a
Author: Michel Dänzer <mdaenzer redhat com>
Date:   Thu Jul 7 18:22:33 2022 +0200

    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: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2498>

 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 23141f1c93..ad306225c8 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 =


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]