Always use an ancestor scroll clip of all direct children, or the original
scroll clip if the children don't share the same scroll clip tree.
Unfortunately this requires another pass over the stacking context display list.
Also, fix clips, scroll clips and creation order of blend items:
If a clipped mix-blend-mode item contains absolute / fixed positioned items,
those items should not be clipped, same for blend container items.
When a transform item contains blend modes, create the blend container inside
the transform.
Don't do tree comparisons on scroll clips from different scroll clip trees.
If the inner scroll clip is nullptr, because it was cleared, it will look like
it's the ancestor of the outer non-nullptr scroll clip.
These changes don't look very related, but it was very hard to get tests passing
with only some of the changes and not the others, and after having spent two
weeks on this patch I'm not thrilled about going back and checking exactly which
change was necessary to fix which test failure.
MozReview-Commit-ID: IKGciUBrdNa
This makes sure that for example the bounds of an opacity item are not empty if
the opacity item contains a scroll frame whose contents are currently scrolled
offscreen but still inside that scroll frame's display port.
On its own, this changeset causes test failures due to missed optimizations
because the bounds of many opacity items are now too large. That's because of
the way we're setting scroll clips on opacity items at the moment: Even if the
opacity is inside a scroll frame, we're currently only setting that scroll
frame's scroll clip on the opacity item's contents, not on the opacity item
itself, because the opacity item might also contain other items that are not
scrolled by this scroll frame.
The next patch in this bug will make us only do that when necessary.
MozReview-Commit-ID: 9TtcJ7eQE7U
In nsDisplayListBuilder keep track of the total area of frames which
have been made animated geometry roots due to having animated offset or
margin properties. This is in order to reduce the total area of created
layers. Once the area has reached a certain limit do not allow any more
frames to be AGRs for this reason.
Currently this only applies to AGRs created due to frames having
animated offset or margin properties. This is because we believe this is
a major source of over-layerisation and too high memory usage. This
could easily be extended to include the creation of AGRs due to other
reasons too.
Note that this technically limits the area of AGR frames, not the area
of layers, though it will have a fairly direct impact.
MozReview-Commit-ID: BvgRrC8KMIp
CLOSED TREE
Backed out changeset dbadb8fe5803 (bug 1216001)
Backed out changeset a30593ebd58e (bug 1216001)
Backed out changeset c1646ffa71b4 (bug 1216001)
This adds the value -moz-window-dragging: default as the initial value of the property,
and makes it a [reset] property. This allows us to change the way the window dragging
region is calculated: Elements with -moz-window-dragging: no-drag will now always be
undraggable, even if they are overlapped by -moz-window-dragging: drag elements. That
way we can keep the region calculation simple and don't have to add code to respect
z-ordering.
By changing signature of those two functions, we make compiler complain about
all their existing uses, so we can find all of them and convert them.
Some of the callsites of Get() with those properties are also converted, but not
all of them. It is fine because if there is any incorrect conversion, compilers
is able to find out now. So they are completely typesafe.
This patch makes methods of FramePropertyTable and FrameProperties to be
simple template wrapper functions. Then it converts all references to
FramePropertyDescriptor to use "void" parameter to simulate the current
unsafe behavior.
SmallValueHolder is used for storing small values like int32_t, float,
which can fit in the size of a pointer directly, and thus no lifetime
management is needed.
