[mutter] clutter/frame-clock: Fix handling of equal next_presentation_time_us
- From: Marge Bot <marge-bot src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [mutter] clutter/frame-clock: Fix handling of equal next_presentation_time_us
- Date: Sun, 31 Jul 2022 19:07:49 +0000 (UTC)
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]