This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Just a cleanup patch, this function would be cleaner without the
nesting.
MozReview-Commit-ID: DD48E2HSQOL
--HG--
extra : rebase_source : 79cf6b3eee00149fa5993c10bd69649633307fee
extra : histedit_source : 1fde6b0291acddcf73569b2e43757030c38d9e69
This updates the not-really-correct code to flush the WR pipeline before
doing a readback. It now uses the flushing functions introduced in bug
1417784 to ensure things are flushed properly.
MozReview-Commit-ID: 90BZuLKcjUi
--HG--
extra : rebase_source : 2180aa0ac7ff7b46467e0c24094fcc99479120f7
This updates the GetTargetAPZC function to produce a
HitTestingTreeNodeAutoLock out-param instead of a
RefPtr<HitTestingTreeNode>, to ensure that the node can be used safely
in calling functions. It then propagates that change outward as needed,
which covers all the scrollbar dragging code.
MozReview-Commit-ID: 43K4eSECb4E
--HG--
extra : rebase_source : b34a880c6fd60069f7a4fa0527cbb5e903085356
This adds the HitTestingTreeNodeAutoLock RAII class that allows using
a HitTestingTreeNode safely outside a tree lock, and ensures that the
node won't get destroyed or recycled concurrently.
MozReview-Commit-ID: 8Tb3vdIeUgr
--HG--
extra : rebase_source : 6eed3e733edcaa4088da52882a9b3dc8c2355c2e
This patch makes three related changes:
- A non-functional change that factors a IsRecyclable function on
HitTestingTreeNode.
- A non-functional change that sprinkles proof-of-tree-lock arguments to
a few HitTestingTreeNode functions, to ensure at compile-time that they
can only be called while holding the tree lock.
- A functional change that stops clearing mLayersId in
HitTestingTreeNode::Destroy, so that if a node is non-recyclable, and
it gets Destroy()'d while other code still has a RefPtr to it, that
other code can still read the layers id off in a safe manner.
These changes provide a stronger set of checks around node recycling,
and allows for a safe mechanism to use a HitTestingTreeNode on the
controller thread without having to lock the entire APZ tree. The
mechanism is effectively a per-node lock, which will be added in the
next patch.
MozReview-Commit-ID: DBIjFDZJwhE
--HG--
extra : rebase_source : 318c27c4473e54b30a0393fca6c2fc76083036b2
This defines three flushing functions that flush different parts of the
WR pipeline. Using all three guarantees that everything sent to WR will
have been flushed. This is what we need to do in SyncWithCompositor to
ensure that it meets the API contract.
In addition, this patch updates the existing FlushRendering function to
use the new functions (no functional changes intended here).
MozReview-Commit-ID: GzxwpF4JT04
--HG--
extra : rebase_source : 1a8cf434d1280902906da257ae63751da7ffd114
Instead of notifying the AsyncImagePipelineManager on the compositor
thread via the CompositorBridgeParent, we can send it the new pipeline
info directly from the RenderThread after the update happens. This
effectively splits the AsyncImagePipelineManager update-processing into
two parts: one that takes in the new pipeline info and one that process
it. This allows us to invoke the processing step from other code running
on the compositor thread, which we will need to do in the next patch.
MozReview-Commit-ID: 7xhm8I7bY4C
--HG--
extra : rebase_source : bfa62e326fd830bc2ef771138e5008fb2bc0d6b8
We do a silent upcast from CompositorBridgeParent* to the base class and
pass it around as a CompositorBridgeParentBase* for no reason. Avoiding
this simplifies the code slightly and avoids virtual function overhead.
We do need to move a couple of functions in CompositorBridgeParent from
protected scope to public scope.
MozReview-Commit-ID: 9Zq3GwxEXpr
--HG--
extra : rebase_source : 67346159e7d99ca7fc2fe0052e85aa6618b50d27
In order to have useful Wayland builds we need ability to switch
between GL backends run-time - to use EGL backend for Wayland and GLX backend for X11.
GL_PROVIDER_GLX is used exclusively for GLX GL backend, so let's replace GL_PROVIDER_GLX
build-time check by more general MOZ_X11 check which determines X11 dependent code
and it's valid for both X11 and Wayland builds.
MozReview-Commit-ID: HYobrHveoaP
--HG--
extra : rebase_source : 2d359355ee747f5898d27d8a28d66114f4135f5b
This commit moves FlushAsyncPaints to EndTransactionInternal, which allows
us to continue async painting during DLB and FLB. We still flush async paints
before rasterizing into layers as we aren't triple buffered.
--HG--
extra : amend_source : 6ee4f511008c60fe1f52f7a260ef7d5b5e3c0c92
In cases where we were carrying down a transform from a
nsDisplayTransform and then applying it to a child item's WRLSD, we
could get incorrect behaviour when that child item had a different ASR
(and therefore had a different APZ instance). This patch corrects that
behaviour by ensuring that when we run into this case we fall back to
creating two WRLSD items instead of one, where the new WRLSD is the
parent of the other one, and holds the transform. The child WRLSD has
the data from the child item's ASR.
MozReview-Commit-ID: BE6HuZjwc8v
--HG--
extra : rebase_source : 436e81d1b6b1fcda44ef77b21eb893075d294f41
Instead of just storing the gfx::Matrix from the nsDisplayTransform on
the stacking context for scrolldata use, we now store a pointer to the
entire nsDisplayTransform item. We will need this in the next patch.
This patch should not have any functional changes.
MozReview-Commit-ID: 7qsZpL3Ka0X
--HG--
extra : rebase_source : b42957c83ef0591e72fa5b58ceb6650fda96e0b2
We should always have the pipeline information for in-process things like
async images, but for cross-process iframes we might not have the information
right away if the content process doesn't get around to sending it for a while.
MozReview-Commit-ID: 18F5nqilXoV
--HG--
extra : rebase_source : 610046cbaaefb38b8e11bda857fd64a00722df27
This lets us improve the illuision that there's not an intermediate surface
being used when drawing SVG. i.e. if content is transformed by 0.5px
the 0.5px transform is included when drawing the SVG content.
MozReview-Commit-ID: ChfbTFblVdR
--HG--
extra : rebase_source : 24144fe05b73ceeaa8499218fdae82035f674e39
Capture a snapping surface transform. This is used
by svg/blob code to compute an fractional offset
to the nearest intermediate surface.
MozReview-Commit-ID: 6EFNvluvzvA
--HG--
extra : rebase_source : f26e7fa823883e93742970c2e8d687319a7eaf5b
I believe this was a left-over from an old strategy where we didn't clear the
items, tried to reuse them but kept made an invalid rect for the old size. Now
that we clear the items this shouldn't be needed. I added the assert to make
sure things are what we expect.
MozReview-Commit-ID: 9btmmSmkl8S
--HG--
extra : rebase_source : 698f4a7e0fb802698f3e86b9fa8e654c5d604ec4
Even if the sticky item has a fixed descendant, we want to use the
sticky container item's "real" ASR when computing the WR clips because
otherwise the WR item doesn't get attached to the correct scrolling
layer.
MozReview-Commit-ID: JVnzEIBeLKp
--HG--
extra : rebase_source : 806e43eb65d46eb5151e21b0a5eb09168b2df82d
This is the other half of the commit renaming the TileUnit to TileCoordUnit. It
also includes some small style cleanups.
--HG--
extra : rebase_source : ebf7a275bed518d1419a2e3c23b67f36601a1089
SingleTiledContentClient has it's own file and this helps make ContentClient slimmer.
--HG--
rename : gfx/layers/client/TiledContentClient.cpp => gfx/layers/client/MultiTiledContentClient.cpp
rename : gfx/layers/client/TiledContentClient.h => gfx/layers/client/MultiTiledContentClient.h
extra : rebase_source : 7c70cfa04f9faa840b2aa8a81680486e4ed0245e
TileCoord is a (very slightly) better name for this unit in my opinion, and I'd
like to add a TileBuffer unit in the future which might get confused if there
is an unprefixed Tile unit.
--HG--
extra : rebase_source : 968f508f2195c12fd4840e2415130b1b36fd3e29
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : a130f1cf22973910767e96c69962d8b621c0d368
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : f7cdc1b46fbca96b2124582f29c791f8944c1fc9
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : 3e8cc6c9cd6fb79ab1f7ec3d1e38a34a2c7f6011
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : e5643b83914b47889e4bde6c0f8658fedb3d54fc
