Confirmed users
586
edits
Platform/GFX/APZ: Difference between revisions
→Where to go for more answers: point to slack
(Update APZ documentation) |
(→Where to go for more answers: point to slack) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 35: | Line 35: | ||
* 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. | * 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::GetCurrentAsyncTransform()). The APZC modifies this transform as the user pans and zooms. | * Every time the compositor composites a frame, it queries each APZC for its current async transform (see AsyncPanZoomController::GetCurrentAsyncTransform()). The APZC modifies this transform as the user pans and zooms. | ||
* APZCs can schedule a composite by calling CompositorParent::ScheduleRenderOnCompositorThread(). | * APZCs can schedule a composite (for the next frame of a scroll animation, for instance) by calling CompositorParent::ScheduleRenderOnCompositorThread(). | ||
=== Widget code === | === Widget code === | ||
| Line 60: | Line 60: | ||
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. | 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 some platforms there are not only multiple threads but also multiple processes. In this setup, only the | On some platforms there are not only multiple threads but also multiple processes. In this setup, the compositor lives in the GPU process (if there is one - currently Windows only), or the UI process otherwise. All the APZCs live in the same process as the compositor, even ones corresponding to layers from a content process. | ||
== Coordinate systems == | == Coordinate systems == | ||
| Line 68: | Line 68: | ||
* [https://staktrace.com/spout/entry.php?id=800 Unraveling coordinate systems] | * [https://staktrace.com/spout/entry.php?id=800 Unraveling coordinate systems] | ||
* [https://staktrace.com/spout/entry.php?id=801 Unraveling coordinate systems, part 2] | * [https://staktrace.com/spout/entry.php?id=801 Unraveling coordinate systems, part 2] | ||
* [ | * [https://searchfox.org/mozilla-central/rev/6f86cc3479f80ace97f62634e2c82a483d1ede40/gfx/layers/apz/src/APZCTreeManager.cpp#2795 The comment above APZCTreeManager::GetScreenToAPZCTransform()] | ||
* [https://bug935219.bugzilla.mozilla.org/attachment.cgi?id=8380975 Diagram illustrating the coordinate confusion that gave rise to bug 935219] | * [https://bug935219.bugzilla.mozilla.org/attachment.cgi?id=8380975 Diagram illustrating the coordinate confusion that gave rise to bug 935219] | ||
| Line 77: | Line 77: | ||
This logging can be turned on by setting the "apz.printtree" pref to "true". | This logging can be turned on by setting the "apz.printtree" pref to "true". | ||
Additional | Additional logging can be enabled by looking for *_LOG macros at the top of .cpp files, and setting the MOZ_LOG environment variable appropriately. For example, setting <tt>MOZ_LOG=apz.inputqueue:4</tt> is often useful for tracing input events through the APZ code. | ||
== Main APZ-related projects on the horizon == | == Main APZ-related projects on the horizon == | ||
See [https:// | See [https://github.com/orgs/FirefoxGraphics/projects/7 the APZ planning GitHub project]. | ||
== FAQ == | == FAQ == | ||
| Line 99: | Line 99: | ||
== Where to go for more answers == | == Where to go for more answers == | ||
APZ now has its own | APZ now has its own matrix channel, #apz:mozilla.org. You can also try #gfx:mozilla.org and #developers:mozilla.org. Ping kats, botond, mstange, or tnikkel. | ||