This is needed because blending for nsDisplayBackgroundImage items will soon
happen outside of nsDisplayBackgroundImage::Paint, it will be done by an
nsDisplayBlendMode item that wraps the nsDisplayBackgroundImage item.
MozReview-Commit-ID: 20cILOGVFEG
--HG--
extra : rebase_source : 306725c99a1cd8d450149482817b8b51bc660908
We're going to use it both for background-blend-mode and for mix-blend-mode.
MozReview-Commit-ID: 6zKCDSkLspc
--HG--
extra : rebase_source : 81b4691d2b74e56c634bdf08f85636ba2abbf486
I've decided to fix this in a very explicit way. The only "magic" part that's
left is how we decide that the AGR of the perspective item is outside the
scrolled frame (and I'm not sure myself how that works).
I didn't want to change what scroll clips we set on what items, because the
scroll clip really belongs on the perspective item, because that's the item
that needs to be clipped, and it should also be the item that should be
scrolled if it weren't for the fact that APZ wouldn't know that it should
apply the perspective transform before the APZ transform.
MozReview-Commit-ID: BBw8VPohQI4
--HG--
extra : rebase_source : 9e11441af2b5dab93a5908236e153fc6cd2c3d8b
extra : histedit_source : 7b3dd75afa92346856765284be48df5618821326
This isn't really about regular clips, it's about scroll clips. If the inner
item has an unnecessary scroll clip (one that's already on the parent), this can
cause the inner item's bounds to be larger than necessary because, after the
first patch in bug 1238564, it will include the whole bounds of async-scrollable
scroll frames.
Also, if e.g. the inner item is an opacity item, and it has a scroll clip that's
not just the innermost ancestor scroll clip of all of its children, then
FrameLayerBuilder's mContainerBounds == mAccumulatedChildBounds assertion can
fail if the opacity item gets flattened away, because the child bounds won't
have been enlarged for the scroll clip.
There must be a better way to do the clip resetting in
nsFrame::BuildDisplayListForStackingContext - the code is not pretty at all.
But I'd rather get the tests passing first before we figure out how to clean it
up.
MozReview-Commit-ID: E1DdpN546va
--HG--
extra : rebase_source : ecf4774a47978fb0aa5ebde9346cf464ebc60ab6
extra : histedit_source : 9395ca5f74413d887df3b7fa54cad726742dca30
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
--HG--
extra : rebase_source : e570f16ecedd80cba16051f0e1ac66764bc95815
extra : histedit_source : fcfbcbc254aaf93594d9d80c117d6ec945805993
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
--HG--
extra : rebase_source : 51cab60bd27e1a7e3c2d6b8d791b79fe3b3baa94
extra : histedit_source : ba421898e442d08f7f711d13f71a693c34d908bb
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : source : bd88a2e478e23edf1845f724a32fef908c8cc007
Wes Kocher
Markus Stange
Mats Palmgren
Nathan Froyd
Kartikaya Gupta
Sebastian Hengst
Shing Lyu
Xidorn Quan
CJKu
Seth Fowler
Jonathan Watt
Carsten "Tomcat" Book