This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.
Differential Revision: https://phabricator.services.mozilla.com/D19699
This patch is an attempt to separate the two and avoid accidentally getting into an inconsistent state.
WebRenderImageData manages resources for images that are shared with webrender, while WebRenderFallbackData manages state to render content, in most case in a blob image.
if the fallback data needs to render into a TextureClient, it creates a WebRenderImageData to hold on to the shared texture, but does not inherit from it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19565
--HG--
extra : moz-landing-system : lando
We already avoid scene rebuilding for animated image frame updates, but
we can easily apply this to still images. If the decoding is happening
slowly and in chunks for some reason (really large image, slow network),
then we may save some work.
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
This commit contains the Gecko-side changes from WebRender PR#3277:
- Dedicated DirtyRect type.
- Separate the blob image APIs from regular image ones.
Differential Revision: https://phabricator.services.mozilla.com/D12463
--HG--
extra : moz-landing-system : lando
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
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 function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This just adds the boilerplate that goes with the new protocol, without
adding any of the actual messages. The protocol is managed by PGPU, and
there will be one instance per compositor. The parent side lives on the
main thread of the GPU process, and the child side lives on the main
thread of the UI process. The protocol is only instantiated if the GPU
process is active.
MozReview-Commit-ID: J4VzwmEfYTa
--HG--
extra : rebase_source : 397ddda8b0e76e5ed5f63783b1220ed7b4414d99
This lets us avoid having to check whether we have the right one when getting them.
MozReview-Commit-ID: 9YDiSd7AekB
--HG--
extra : rebase_source : 4e9ce48075fa02eba83209f545181a0883e7551e
The flag of force update is only for fallback items. Fallback items can't share the images with other items.
So I replace 'aForceUpdate' with 'aFallback' and remove some unnecessary checks.
MozReview-Commit-ID: Dcu95FZXlUz
--HG--
extra : rebase_source : 1ec96e0b5d39cc5760b4b5490c5ca9ccbc1933c6
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
We have too many layers-free things in WebRenderLayerManager. I create a new
class WebRenderCommandsBuilder and move some functions and variables from
WebRenderLayerManager to WebRenderCommandsBuilder.
MozReview-Commit-ID: BJi1E51W7ax
--HG--
extra : rebase_source : ddbfb044d467430403a3c480030ef9dec803c9f7
Instead of always discarding the compositor animation id, and then
sometimes un-discarding it (which involves a linear lookup in nsTArray),
this patch now has the WebRenderLayerManager keep a set of active
animation ids, and uses that to avoid discarding the same animation
twice.
In addition, because the display item can be destroyed at any time (e.g.
in the middle of an animation), we were previously "leaking" compositor
animations in that the compositor side never got notified to discard the
IDs. This resulted in infinite composition loops. This patch solves this
problem by having any unused WebRenderAnimationData trigger discard of
the animation id during destruction. This way, even if the nsDisplayItem
is deleted in the middle of the animation we have a fallback mechanism
to discard the id.
MozReview-Commit-ID: 8G3EYHcg9Kl
--HG--
extra : rebase_source : 45e99a0d71a76a15b7fc7a0d498a6149501a722d
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
Doug Thayer
Ciure Andrei
Ryan Hunt
Sylvestre Ledru
Andrew Osmond
Nicolas Silva
Kartikaya Gupta
Bogdan Tara
Dzmitry Malyshau
Hiroyuki Ikezoe
sotaro
Jeff Muizelaar
vincentliu
Ethan Lin
Sebastian Hengst
Daniel Holbert
Coroiu Cristina
Morris Tseng