Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
--HG--
extra : rebase_source : 27e7d90ce60c7f702fe77d8a3a0f7e3ae3e4a4ff
ScrollDirection variables for which NONE was a valid value are replaced with
Maybe<ScrollDirection>.
I also took the opportunity to change the remaining ScrollDirection
enumerators to eTitleCase as per style guide.
MozReview-Commit-ID: GWejQR2HqH5
--HG--
extra : rebase_source : 6f8ad222caf73f9e02d772234f188eac4aac9301
We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: JKU4UXvdR2e
--HG--
extra : rebase_source : 77f49787e8953520dc56ea4a8f9286b35d6942b8
We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: EX57VvaZv8A
--HG--
extra : rebase_source : 7ea4c8bb2716821bf7069158fdf9729fb6137a35
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
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
--HG--
extra : rebase_source : 63fec656440c8bee322f069a4466a311ebcd0f7d
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
--HG--
extra : rebase_source : bd3fcfed5caab5d8edfbd29a8e505daf9e8ff95f
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
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
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
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
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
--HG--
extra : rebase_source : 6c888252813fbfc01baf5d4bb1728d989ee1586c
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
--HG--
extra : rebase_source : ecb4773c4fd98adfc8e254bff697027e24c64dbd
extra : source : 2288643cc9361735fd87b35801393bd2da47d952