I leave findings about the Firefox code here for future reference.

General

base points

flow

code patterns

Variant Matching

https://searchfox.org/firefox-main/rev/fdd583cd5a10d051053acda8b760c3bd5d800034/gfx/layers/apz/util/APZTaskRunnable.cpp#23-51

auto requests = std::move(mPendingRequestQueue);
[...]
while (!requests.empty()) {
    struct RequestProcessor {
        GeckoContentController* mController;
        void operator()(const RepaintRequest& aRequest) {
            mController->RequestContentRepaint(aRequest);
        }
        void operator()(const APZStateChangeRequest& aRequest) {
            mController->NotifyAPZStateChange(aRequest.mGuid, aRequest.mChange,
                                                aRequest.mArg,
                                                aRequest.mInputBlockId);
        }
    };
    requests.front().match(RequestProcessor{controller.get()});
    requests.pop_front();
}

caviats

• There are several processes other than the parent, the content, and the GPU.
  • You can check them using about:processes.

APZ

base points

• scrollWheel:(NSEvent*)theEvent()

  • A native scroll event comes from here.
  • https://searchfox.org/firefox-main/rev/fdd583cd5a10d051053acda8b760c3bd5d800034/widget/cocoa/nsCocoaWindow.mm#2699

• nsIWidget::MayStartSwipeForAPZ()

  • After APZ processes an event, this determines swipe-to-navigation should be triggered.
  • https://searchfox.org/firefox-main/rev/fdd583cd5a10d051053acda8b760c3bd5d800034/widget/nsIWidget.cpp#2337

• nsRefreshDriver::Tick()

  • nsRefreshDriver is initialized in nsPresContext::Init().
    • A document tree in one process may have one nsRefreshDriver, i.e. the top document and the same site iframes share one nsRefreshDriver.
  • This is synced with vsync and triggers "updating the rendering".
  • At the beginning, APZ scrolls are synced.
  • https://searchfox.org/firefox-main/rev/fdd583cd5a10d051053acda8b760c3bd5d800034/layout/base/nsRefreshDriver.cpp#2278

• RemoteContentController::RequestContentRepaint()

  • This syncs a scroll happened in APZ with the relevant content process.
  • https://searchfox.org/firefox-main/rev/fdd583cd5a10d051053acda8b760c3bd5d800034/gfx/layers/ipc/RemoteContentController.cpp#54

• ScrollContainerFrame::mApzScrollPos

  • The latest scroll position we've sent or received from APZ.
  • https://searchfox.org/firefox-main/rev/b333f4353e8b4908bf3375e110f293aae894295a/layout/generic/ScrollContainerFrame.h#1466

flow

How are scrolls happened on the APZ side reflected on the content process?

1. APZ controller on the compositor thread calls RemoteContentController::RequestContentRepaint().
2. Via IPC, that makes APZ child on the main thread put an early runner.
3. The early runner is processed at the beginning of nsRefreshDriver::Tick(), which is almost equivalent to "update the rendering".
4. The early runner eventually calls ScrollContainerFrame::ScrollToImpl() and it sets the received APZ scroll info to ScrollContainerFrame::mApzScrollPos.

caviats

• "Layer Tree" is a legacy module, which was the final output on the side of content process.
  • Nowadays, the final output of a content process is WebRender Display List.

Servo

base points

flow

caviats