Transform display item may have multiple properties, so it's better to
use display item type as the input.
Also, factor some code out of AddAnimationsForProperty, so we can easier
to extend this for multiple properties.
We will pass a list of layers::Animation to the compositor thread. In
this list, the animations belonging to the same property are grouped together,
so we can easily separate the animations by property and sample the animations
for each property on the compositor thread. (Will do this in Bug 1425837.)
Depends on D19628
Differential Revision: https://phabricator.services.mozilla.com/D19629
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--HG--
extra : moz-landing-system : lando
FrameLayerBuilder needs to clear this flag by DisplayItemType, so we add
a new function for it.
Differential Revision: https://phabricator.services.mozilla.com/D19630
--HG--
extra : moz-landing-system : lando
If we destroy at the same time as removal, then the destruction can destroy other objects which in turn might remove frame properties and mess up the frame property table.
This should cover all ways the webrender user data can get deleted from a frame property.
The nsIFrame::RemoveDisplayItemDataForDeletion bit doesn't seem necessary to fix the intermittent but I think it is still necessary.
Let ActiveLayerTracker track individual transforms. (Will add
motion-path in the future.)
Besides, using a property set for transform and opacity is more efficient,
so let's change it. For background position, we use a different code path,
so we can have more restrictions in IsStyleAnimated.
Differential Revision: https://phabricator.services.mozilla.com/D19631
--HG--
extra : moz-landing-system : lando
-moz-tab-size, border-image-outset and border-image-slice.
This is not a particularly interesting patch, just removes some code. We can
remove way more code when a few related properties are also ported.
Differential Revision: https://phabricator.services.mozilla.com/D19825
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
r?njn only because this is the first example that adds any actual subcategories.
Differential Revision: https://phabricator.services.mozilla.com/D11340
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Both of reftests in this commit are based on an exmaple [1] in the Viewports
Explainer written by David Bokan.
position-fixed-out-of-view.html fails without the fix because the position:fixed
element is rendered at the right edge of the visual viewport so that it's
visible in the first place.
position-fixed-on-minimum-scale-size.html does NOT fail without the fix either
because the position:fixed element sticks at the right edge of the visual
viewport so that it still be there even after the visual viewport offset has
been changed.
[1] https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md#chrome-2
Differential Revision: https://phabricator.services.mozilla.com/D18797
--HG--
extra : moz-landing-system : lando
It doesn't really need to allocate a lot. Furthermore, it doesn't really need to
create a message and such if we've already warned in this document.
Differential Revision: https://phabricator.services.mozilla.com/D18583
--HG--
extra : moz-landing-system : lando
The API to create a sticky spatial node doesn't allow us to set a clip
chain that will apply to all the contents of the sticky node. This means
that when the ClipManager sets up the clip state for the sticky node,
the clip chain for it is dropped. Everything still works currently
because the contents of the sticky node have their own clip chains whose
parent link will include the sticky node's clip chain. However, in the
next patch we're going to sever that parent link to fix other issues,
and so we will break this mechanism. This patch fixes it up by
explicitly applying the sticky node's clip chain to the stacking context
that contains all the sticky contents. This ensures all those items pick
up the clip chain.
Differential Revision: https://phabricator.services.mozilla.com/D18100
--HG--
extra : moz-landing-system : lando
Would be pretty surprising if a perspective transform scrolled stuff in an
iframe for example.
Differential Revision: https://phabricator.services.mozilla.com/D17905
--HG--
extra : moz-landing-system : lando
