This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
The pending transforms must have been computed using the older scroll offset
values, which means that updating the scroll offsets without recomputing the
transforms will make them wrong. If we do an empty transaction for the scroll
offset updates, the transforms will not get computed. This patch catches this
scenario and schedules a full paint instead of the empty transaction instead.
The case where the scroll offset is modified *before* the transform is already
handled by code in nsIFrame::TryUpdateTransformOnly.
MozReview-Commit-ID: I5s5J7BS1ru
In gecko, it's possible to generate lots of animation ids per layer if animations are changed.
It also introduces lots of memory allocation/deallocation in CompositorAnimationStorage(HashTable).
Generate fixed animations id per layer should help the memory usage and reduce CPU time for memory allocation.
MozReview-Commit-ID: 1hWUD5gNBJH
In order to have the scrollbar thumbs reflect the async scroll position, we're
going to re-use the API for OMTA. That is, we set an animation id on the
stacking context for the scroll thumb, and we'll update the transform on the
stacking context at composite time based on the async scroll position. For this
to work we need to ensure that the scroll thumb does in fact have an
animation id set on it.
MozReview-Commit-ID: 6TvRemxRUrR
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
In bug 1223658 we separated out the delay from the start time but we failed to
remove it from this calculation. As a result, when a pending animation begins it
will have the delay applied twice (once here, and once when it is sampled on the
compositor). This will happen until the layer is next updated.
This bug was not exposed by any existing tests since we don't use this code path
when the refresh driver is under test control. Furthermore, the one test that
was supposed to cover this was refactored in such a way that it stopped testing
this code path. That test is restored earlier in this patch series and enabled
in this patch.
MozReview-Commit-ID: B2KR7YaPsMK
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
gfx/layers/Layers.cpp:1944:33 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1945:33 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1946:33 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1949:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1950:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1951:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1952:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1953:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1954:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1955:37 [-Wcomma] possible misuse of comma operator here
gfx/layers/Layers.cpp:1956:37 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: 9lMJZrPRtTV
We couldn't tell the difference between a null StyleAnimationValue and
transform:none on the compositor. This was not a problem before, since we didn't
need the null StyleAnimationValue on the compositor, because the null
StyleAnimationValue have to be passed with composite:add flag, and in the case of
composite:add we just used the underlying value, i.e. we didn't use the null
value at all.
But for normal additive animations, we have to check the null StyleAnimationValue
to tell whether we are processing a missing keyframe or not.
So in this patch, Animatable can be null_t to represent the null
StyleAnimationValue, and as a result of this change, we can drop
BaseAnimationStyle.
MozReview-Commit-ID: Au41ujHgPpU
