Confirm
85
edits
Changes
update some broken links (as a result of code files moving), also switched mxr links -> dxr
== AsyncPanZoomControllers ==
Inside the APZ module, every scrollable layer has an [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/gfx/layers/ipcapz/src/AsyncPanZoomController.h AsyncPanZoomController] (APZC). Scrollable layers roughly correspond to the root document, documents in iframes, and overflow:scroll elements. See [[Platform/GFX/OffMainThreadCompositing|OMTC]] for more information about layers.
The APZCs are arranged in a tree whose structure reflects the structure of the layer tree containing the layers that they correspond to, except that the APZC tree only has nodes for scrollable layers, while the layer tree has nodes for all layers. The APZC tree is managed by a class called [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/gfx/layers/compositeapz/src/APZCTreeManager.h APZCTreeManager]. The APZCTreeManager is the interface through which the outside world interacts with the APZ module - there is no access to the APZCs directly, but the APZCTreeManager provides methods that operate on a specific APZC in the tree.
These methods identify an APZC using three integer identifiers, grouped in a structure called '''ScrollableLayerGuid'''. The three identifiers are:
# A '''layers id''', which identifies the layer tree that the scrollable layer belongs to. Layers ids are maintained by the compositor, with CompositorParent::RootLayerTreeId() returning the layers id for the root layer tree, and CompositorParent::AllocateLayerTreeId() allocating a layers id for a new layer tree.
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: [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.h RenderFrameParent]/[httpshttp://mxrdxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameChild.h RenderFrameChild] and [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]/[httpshttp://mxrdxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]* On Metro: [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroWidget.h MetroWidget] and [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroInput.h MetroInput]* On Fennec (which doesn't use the APZ yet): [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoAppShell.java GeckoAppShell] and [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/GeckoLayerClient.java GeckoLayerClient], which communicate with native code via [http://mxrdxr.mozilla.org/mozilla-central/source/widget/android/AndroidJNI.cpp AndroidJNI].
The widget code interacts with the APZ in the following ways:
** 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 '''[httpshttp://mxrdxr.mozilla.org/mozilla-central/source/gfx/layers/ipcapz/public/GeckoContentController.h GeckoContentController]'''. The implementation of this interface is different for each platform. 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 the RemoteContentController implementation, while those representing scrollable elements in the parent process will use a different implementation (currently being developed in {{bug|912657}})).
GeckoContentController allows the APZ to do the following:
== 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). [httpshttp://mxrdxr.mozilla.org/mozilla-central/source/gfx/layers/compositeapz/src/APZCTreeManager.h APZCTreeManager.h] documents which APZCTreeManager methods can be called on which threads.
On B2G, 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 thread.
* [https://staktrace.com/spout/entry.php?id=800 Unraveling coordinate systems]
* [https://staktrace.com/spout/entry.php?id=801 Unraveling coordinate systems, part 2]
* [http://mxrdxr.mozilla.org/mozilla-central/source/gfx/layers/compositeapz/src/APZCTreeManager.cpp#900 1052 The comment above APZCTreeManager::GetInputTransforms()]
* [https://bug935219.bugzilla.mozilla.org/attachment.cgi?id=8380975 Diagram illustrating the coordinate confusion that gave rise to bug 935219]
* Get APZ turned on for desktop platforms - {{bug|944938}} for OS X
* Smooth scrolling API for content/script - {{bug|928839}}
See also [https://etherpad.mozilla.org/apz-planning the APZ planning etherpad].
== FAQ ==
