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
We are going to re-enable the assertion with a proper fix in bug 1459775.
MozReview-Commit-ID: 2jy6vIImqD
--HG--
extra : rebase_source : ce81b8b2f7dfb47f7db07e820989a65eac38859a
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
This allows frames to be generated by the render backend thread even
while the scene builder thread is busy with a long scene build. The
GenerateFrame transaction also contains APZ and OMTA information, so
this allows the user to scroll and view OMTAnimations during long scene
builds.
MozReview-Commit-ID: KG5YC2KwIaH
--HG--
extra : rebase_source : 3ba559aa22a3a036a3b3a034ea20caacdc8c864a
In particular, this change makes it so that we are not holding the lock
when we clone the WebRenderAPI, because that can result in a deadlock.
MozReview-Commit-ID: 33OGZdFMjEA
--HG--
extra : rebase_source : 4a1aeb81e3316a119d6b0aa798d827314543a70b
We no longer need them since in the previous commit we make sure subsequent
ticks happens for animations in delay phase.
MozReview-Commit-ID: F68wCCsCEiE
--HG--
extra : rebase_source : d6ebe9bfa90a767154cea04255dbf4a5403674fe
mAnimStorage->AnimatedValueCount() returns zero in the case where all
animations are in delay phase, even in such case, we should update the previous
timestamp.
MozReview-Commit-ID: 5Dds1YjfVh9
--HG--
extra : rebase_source : 759b7b4d9e5aa23542a31593674683fbef2dbc47
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : f2c59cb3bdb3affc5846e65ccbaad7dbc069d0ad
The test case has a fixed item A inside a scrollframe B which is inside
a reference frame C which is inside the root scrollframe D. The
ClipManager code currently uses D's scrollid as the scrolling ancestor
for A, because the gecko display list's ASR is set up that way. However,
we really want to set C as the scrolling ancestor, because otherwise the
item A gets hoisted out of C and the transform from C doesn't get
applied to it. This patch ensures that when we enter C, we install an
override so that anything that would have used D's scrollid ends up
using C's, which results in the correct behaviour.
MozReview-Commit-ID: 31tscfT4xWW
--HG--
extra : rebase_source : 03df2fa5519b2592a2c9f598af0f3f1500773718
This is just plumbing, no functional changes yet.
MozReview-Commit-ID: FlmnMVammse
--HG--
extra : rebase_source : edede45a77a829dbd125dc1f18a4c2a4bc8087c1