Bug 1461122 - Ensure we recomposite when getting a main-thread scroll offset update. r?botond draft
authorKartikaya Gupta <kgupta@mozilla.com>
Tue, 15 May 2018 08:49:36 -0400
changeset 795283 ee4f91b5f872e2effabd94ccf691270408277400
parent 795282 de7429880c98078fd5c7aa86f2e326ae2653d7e4
push id109913
push userkgupta@mozilla.com
push dateTue, 15 May 2018 12:50:00 +0000
reviewersbotond
bugs1461122
milestone62.0a1
Bug 1461122 - Ensure we recomposite when getting a main-thread scroll offset update. r?botond With non-WebRender, the composite is triggered unconditionally when we receive the transaction from the content side, so we never needed this. The previous patch adds the composite for the equivalent WebRender codepath, but it's better to do it explicitly in NotifyLayersUpdated as well. The reason for this is that with WebRender, this code runs on the updater thread which is not the same as the compositor thread - so the composition that is scheduled from WebRenderBridgeParent upon receiving the transaction might happen before the scroll offset update is actually applied. Triggering a composition from NotifyLayersUpdated should be a no-op in the cases where a composition is already scheduled, but in cases where it has not been scheduled, it will schedule one to ensure the scroll offset update gets composited properly. MozReview-Commit-ID: Luf76J6QDkr
gfx/layers/apz/src/AsyncPanZoomController.cpp
--- a/gfx/layers/apz/src/AsyncPanZoomController.cpp
+++ b/gfx/layers/apz/src/AsyncPanZoomController.cpp
@@ -4179,16 +4179,19 @@ void AsyncPanZoomController::NotifyLayer
       // Since the scroll offset has changed, we need to recompute the
       // displayport margins and send them to layout. Otherwise there might be
       // scenarios where for example we scroll from the top of a page (where the
       // top displayport margin is zero) to the bottom of a page, which will
       // result in a displayport that doesn't extend upwards at all.
       // Note that even if the CancelAnimation call above requested a repaint
       // this is fine because we already have repaint request deduplication.
       needContentRepaint = true;
+      // Since the main-thread scroll offset changed we should trigger a
+      // recomposite to make sure it becomes user-visible.
+      ScheduleComposite();
     } else if (scrollableRectChanged) {
       // Even if we didn't accept a new scroll offset from content, the
       // scrollable rect may have changed in a way that makes our local
       // scroll offset out of bounds, so re-clamp it.
       mFrameMetrics.ClampAndSetScrollOffset(mFrameMetrics.GetScrollOffset());
     }
   }