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
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
Martin Stransky
Daniel Zielas
Kartikaya Gupta
Ryan Hunt
Andreea Pavel
Jonathan Kew
Andrew Osmond
Jeff Muizelaar
Margareta Eliza Balazs
Matt Woodrow
Hiroyuki Ikezoe
Bogdan Tara
sotaro
James Willcox
Alexis Beingessner
Brian Birtles
shindli