Confirm
586
edits
Changes
Update APZ documentation
* When the compositor receives an update to the layer tree, it propagates this update to the APZCTreeManager by calling APZCTreeManager::UpdatePanZoomControllerTree(). This function updates the tree of APZCs to reflect the tree of scrollable layers in the updated layer tree.
* Every time the compositor composites a frame, it queries each APZC for its current async transform (see AsyncPanZoomController::SampleContentTransformForFrameGetCurrentAsyncTransform()). The APZC modifies this transform as the user pans and zooms.
* APZCs can schedule a composite by calling CompositorParent::ScheduleRenderOnCompositorThread().
=== Widget code ===
The '''widget code''' is a platform-specific component of a browser implementation that interfaces with the native widget implementation. It corresponds roughly to the following pieces of code:* On B2G: [http://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.h RenderFrameParent]/[http://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameChild.h RenderFrameChild] and [http://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]/[http://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]* On Metro: [http://dxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroWidget.h MetroWidget] and [http://dxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroInput.h MetroInput]* On Fennec (which doesn't use the APZ yet): [https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/GeckoAppShell.java GeckoAppShell] and [https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/gfx/GeckoLayerClient.java GeckoLayerClient], which communicate with native code via [http://dxr.mozilla.org/mozilla-central/source/widget/android/AndroidJNI.cpp AndroidJNI]. The widget code interacts with the APZ in the following ways:
* forwards relevant input events to the APZ (APZCTreeManager::ReceiveInputEvent())
* notifies the APZ about Gecko events that are relevant to it, such as:
** a reflow that causes a change in the dimensions of a scrollable layer how content responded to an input event (APZCTreeManager::UpdateCompositionBoundsContentReceivedInputBlock())** a scrollTo performed by content change in the zoom constraints (APZCTreeManager::UpdateScrollOffsetUpdateZoomConstraints())
** a request to zoom in to a rectangle (APZCTreeManager::ZoomToRect())
In addition, the widget code provides APZ with an interface for interacting with Gecko, called '''[http://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/public/GeckoContentController.h GeckoContentController]'''. The implementation of this interface is different for each platformdifferent platforms. It may even be different for different APZCs within one platform (for example, in the B2G browser, APZCs representing scrollable elements in content processes use depending on which process the RemoteContentController implementation, while those representing scrollable elements in the parent process will use a different implementation (currently being developed controller lives in {{bug|912657}})).
GeckoContentController allows the APZ to do the following:
* request a repaint (GeckoContentController::RequestContentRepaint())
* request handling of various gestures, such as single taps, double taps, and long taps (GeckoContentController::HandleSingleTapHandleTap() etc.)* fire async scroll events state change notifications (GeckoContentController::SendAsyncScrollDOMEventNotifyAPZStateChange())* schedule arbitrary actions to be performed on the Gecko thread with a delay (GeckoContentController::PostDelayedTask())
== Threads and processes ==
When OMTC is enabled on a platform (which is a requirement for using the APZC), the compositor runs on its own thread, called the '''compositor thread'''. APZCs and the APZCTreeManager can be thought of as living on the compositor thread, although they can be used in certain ways by other threads (usually the Gecko thread, or the platform UI thread if there is one). [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/APZCTreeManager.h APZCTreeManager.h] documents which APZCTreeManager methods can be called on which threads.
On B2G, some platforms there are not only multiple threads but also multiple processes, as each app (or in the case of the browser, each tab) has its own process. In this setup, only the parent process has a compositor thread, and all APZCs live in the parent process, even ones corresponding to layers from a child threadprocess.
== Coordinate systems ==
This logging can be turned on by setting the "apz.printtree" pref to "true".
Additional compile-time logging can be enabled by looking for *_LOG macros at the top of .cpp files. INPQ_LOG in InputQueue.cpp is often useful for tracing input events through the APZ code.
== Main APZ-related projects on the horizon ==
If you have questions about anything APZ-related, please add them here, and somebody watching this page will try to answer it.
; What platforms is APZ currently enabled on? [20142016-0109-1413] : As of January 8, 2014, APZ is currently enabled in all B2G processes that are not the root process (i.e. this includes all browser content , Firefox desktop with e10s enabled, and Gaia apps). It is also enabled on Firefox Metro (when running in metro mode)Fennec.
; How does APZ impact the onload event? Will this impact user perceived performance? [2014-01-28] : In general APZ shouldn't really impact the onload event. We might be painting a larger area now but if the app is well-behaved and doesn't trigger a lot of paints the impact from this should not be very large. If there are reports of delayed onload because of APZ, it would be useful to get profiles with and without APZ enabled to compare.
== Where to go for more answers ==
APZ now has its own IRC channel, #apz. You can also try #gfx and #developers. Ping kats, botond, tntnikkel, rbarker, BenWa or Cwiiisdvander.
