||The AndroidDynamicToolbarAnimator is responsible for calculating the position
and drawing the static snapshot of the toolbar. The animator lives in both
compositor thread and controller thread. It intercepts input events in the
controller thread and determines if the intercepted touch events will cause
the toolbar to move or be animated. Once the proper conditions have been met,
the animator requests that the UI thread send a static snapshot of the
current state of the toolbar. Once the animator has received the snapshot and
converted it into an OGL texture, the animator notifies the UI thread it is
ready. The UI thread will then hide the real toolbar and notify the animator
that it is unlocked and may begin translating the snapshot. The
animator is responsible for rendering the snapshot until it receives a
message to show the toolbar or touch events cause the snapshot to be
completely visible. When the snapshot is made completely visible the animator
locks the static toolbar and sends a message to the UI thread to show the
real toolbar and the whole process may start again. The toolbar height is in
screen pixels. The toolbar height will be at max height when completely
visible and at 0 when completely hidden. The toolbar is only locked when it
is completely visible. The animator must ask for an update of the toolbar
snapshot and that the real toolbar be hidden in order to unlock the static
snapshot and begin translating it.
See Bug 1335895 for more details.
||NOTE ON LOCK ORDERING IN APZ **************************
There are two main kinds of locks used by APZ: APZCTreeManager::mTreeLock
("the tree lock") and AsyncPanZoomController::mRecursiveMutex ("APZC locks").
There is also the APZCTreeManager::mTestDataLock ("test lock") and
APZCTreeManager::mMapLock ("map lock").
To avoid deadlock, we impose a lock ordering between these locks, which is:
tree lock -> map lock -> APZC locks -> test lock
The interpretation of the lock ordering is that if lock A precedes lock B
in the ordering sequence, then you must NOT wait on A while holding B.
In addition, the WR hit-testing codepath acquires the tree lock and then
blocks on the render backend thread to do the hit-test. Similar operations
elsewhere mean that we need to be careful with which threads are allowed
to acquire which locks and the order they do so. At the time of this writing,
the most complete description we have of the situation. The total dependency
ordering including both threads and locks is as follows:
UI main thread
-> GPU main thread // only if GPU enabled
-> Compositor thread
-> SceneBuilder thread // only if WR enabled
-> APZ tree lock
-> RenderBackend thread // only if WR enabled
-> APZC map lock
-> APZC instance lock
-> APZC test lock
where the -> annotation means the same as described above.
||Cancel all animations
||Attempt to handle a main-thread scroll offset update without cancelling
the animation. This may or may not make sense depending on the type of
the animation and whether the scroll update is relative or absolute.
If the scroll update is relative, |aRelativeDelta| will contain the
delta of the relative update. If the scroll update is absolute,
|aRelativeDelta| will be Nothing() (the animation can check the APZC's
FrameMetrics for the new absolute scroll offset if it wants to handle
and absolute update).
Returns whether the animation could handle the scroll update. If the
return value is false, the animation will be cancelled.
||Represents a transform from the ParentLayer coordinate space of an APZC
to the ParentLayer coordinate space of its parent APZC.
Each layer along the way contributes to the transform. We track
contributions that are perspective transforms separately, as sometimes
these require special handling.
For an AutoDir wheel scroll, there's some situations where we should adjust a
wheel event's delta values. AutoDirWheelDeltaAdjuster converts delta values
for AutoDir scrolling. An AutoDir wheel scroll lets the user scroll a frame
with only one scrollbar, using either a vertical or a horzizontal wheel.
For more detail about the concept of AutoDir scrolling, see the comments in
This is the APZ implementation of AutoDirWheelDeltaAdjuster.
||Compare two coordinates for equality, accounting for rounding error.
Use both FuzzyEqualsAdditive() with COORDINATE_EPISLON, which accounts for
things like the error introduced by rounding during a round-trip to app
units, and FuzzyEqualsMultiplicative(), which accounts for accumulated error
due to floating-point operations (which can be larger than COORDINATE_EPISLON
for sufficiently large coordinate values).
||This class records information relevant to one "checkerboard event", which is
a contiguous set of frames where a given APZC was checkerboarding. The intent
of this class is to record enough information that it can provide actionable
steps to reduce the occurrence of checkerboarding. Furthermore, it records
information about the severity of the checkerboarding so as to allow
prioritizing the debugging of some checkerboarding events over others.
||This class is used for tracking chrome and content focus targets and
calculating global focus information from them for use by APZCTreeManager
for async keyboard scrolling.
# Calculating the element to scroll
Chrome and content processes have independently focused elements. This makes
it difficult to calculate the global focused element and its scrollable
frame from the chrome or content side. So instead we send the local focus
information from each process to here and then calculate the global focus
information. This local information resides in a `focus target`.
A focus target indicates that either:
1. The focused element is a remote browser along with its layer tree ID
2. The focused element is not scrollable
3. The focused element is scrollable along with the ViewID's of its
Using this information we can determine the global focus information by
starting at the focus target of the root layer tree ID and following remote
browsers until we reach a scrollable or non-scrollable focus target.
# Determinism and sequence numbers
and others. This makes it impossible to always have the current focus
information in APZ as it can be changed asynchronously at any moment. If we
don't have the latest focus information, we may incorrectly scroll a target
when we shouldn't.
A tradeoff is designed here whereby we will maintain deterministic focus
here is that `setTimeout` and others are already non-deterministic and so it
might not be as breaking to web content.
To maintain deterministic focus changes for a given stream of user inputs,
we invalidate our focus state whenever we receive a user input that may
trigger event listeners. We then attach a new sequence number to these
events and dispatch them to content. Content will then include the latest
sequence number it has processed to every focus update. Using this we can
determine whether any potentially focus changing events have yet to be
handled by content.
Once we have received the latest focus sequence number from content, we know
that all event listeners triggered by user inputs, and their resulting focus
changes, have been processed and so we have a current target that we can use
||This class is used for communicating information about the currently focused
element of a document and the scrollable frames to use when keyboard
scrolling it. It is created on the main thread at paint-time, but is then
passed over IPC to the compositor/APZ code.
||The FlingPhysics template parameter determines the physics model
that the fling animation follows. It must have the following methods:
- Default constructor.
- Init(const ParentLayerPoint& aStartingVelocity, float aPLPPI).
Called at the beginning of the fling, with the fling's starting velocity,
and the number of ParentLayer pixels per (Screen) inch at the point of
the fling's start in the fling's direction.
- Sample(const TimeDuration& aDelta,
Called on each sample of the fling.
|aDelta| is the time elapsed since the last sample.
|aOutVelocity| should be the desired velocity after the current sample,
in ParentLayer pixels per millisecond.
|aOutOffset| should be the desired _delta_ to the scroll offset after
the current sample. |aOutOffset| should _not_ be clamped to the APZC's
scrollable bounds; the caller will do the clamping, and it needs to
know the unclamped value to handle handoff/overscroll correctly.
||Amount of span or focus change needed to take us from the
GESTURE_WAITING_PINCH state to the GESTURE_PINCH state. This is measured as
either a change in distance between the fingers used to compute the span
ratio, or the a change in position of the focus point between the two
||Platform-non-specific, generalized gesture event listener. This class
intercepts all touches events on their way to AsyncPanZoomController and
determines whether or not they are part of a gesture.
For example, seeing that two fingers are on the screen means that the user
wants to do a pinch gesture, so we don't forward the touches along to
AsyncPanZoomController since it will think that they are just trying to pan
the screen. Instead, we generate a PinchGestureInput and send that. If the
touch event is not part of a gesture, we just return nsEventStatus_eIgnore
and AsyncPanZoomController is expected to handle it.
||This class represents a node in a tree that is used by the APZCTreeManager
to do hit testing. The tree is roughly a copy of the layer tree, but will
contain multiple nodes in cases where the layer has multiple FrameMetrics.
In other words, the structure of this tree should be identical to the
LayerMetrics tree (see documentation in LayerMetricsWrapper.h).
Not all HitTestingTreeNode instances will have an APZC associated with them;
only HitTestingTreeNodes that correspond to layers with scrollable metrics
Multiple HitTestingTreeNode instances may share the same underlying APZC
instance if the layers they represent share the same scrollable metrics (i.e.
are part of the same animated geometry root). If this happens, exactly one of
the HitTestingTreeNode instances will be designated as the "primary holder"
of the APZC. When this primary holder is destroyed, it will destroy the APZC
along with it; in contrast, destroying non-primary-holder nodes will not
destroy the APZC.
Code should not make assumptions about which of the nodes will be the
primary holder, only that that there will be exactly one for each APZC in
The reason this tree exists at all is so that we can do hit-testing on the
thread that we receive input on (referred to the as the controller thread in
APZ terminology), which may be different from the compositor thread.
Accessing the compositor layer tree can only be done on the compositor
thread, and so it is simpler to make a copy of the hit-testing related
properties into a separate tree.
The tree pointers on the node (mLastChild, etc.) can only be manipulated
while holding the APZ tree lock. Any code that wishes to use a
HitTestingTreeNode outside of holding the tree lock should do so by using
the HitTestingTreeNodeAutoLock wrapper, which prevents the node from
being recycled (and also holds a RefPtr to the node to prevent it from
||A base class that stores state common to various input blocks.
Note that the InputBlockState constructor acquires the tree lock, so callers
from inside AsyncPanZoomController should ensure that the APZC lock is not
||the block was just created so it has no events
||This class stores incoming input events, associated with "input blocks",
until they are ready for handling.
||This class is an off main-thread <xul:handler> for scrolling commands.
||This class represents a scrolling action to be performed on a scrollable
||This class represents the chain of APZCs along which overscroll is handed
off. It is created by APZCTreeManager by starting from an initial APZC which
is the target for input events, and following the scroll parent ID links
(often but not always corresponding to parent pointers in the APZC tree),
then adjusting for scrollgrab.
||This class allows the owner to track the duration of time considered
"potentially checkerboarding". This is the union of two possibly-intersecting
sets of time periods. The first set is that in which checkerboarding was
actually happening, since by definition it could potentially be happening.
The second set is that in which the APZC is actively transforming content
in the compositor, since it could potentially transform it so as to display
checkerboarding to the user.
The caller of this class calls the appropriate methods to indicate the start
and stop of these two sets, and this class manages accumulating the union
of the various durations.
||This lightweight class holds a pointer to an input event that has not yet
been completely processed, along with the input block that the input event
is associated with.
||RecentEventsBuffer: maintains an age constrained buffer of events
Intended for use with elements of type InputData, but the only requirement
is a member "mTimeStamp" of type TimeStamp