After enabling animations running on compositor, it seems to me that we
can enable reftests in layout/reftests/web-animations without intermittents.
MozReview-Commit-ID: 5Whwm0UZ8nQ
--HG--
extra : rebase_source : a0db68e521ff3143bf8f52d3e31eaff115f35bb2
This fixes the failure of
layout/reftests/pagination/dynamic-abspos-overflow-01-cols.xhtml with
the primary patch in bug 1308876.
Since it is an independently testable failure, I'm posting it as a
separate bug.
Without the patch, both reftests fail to rewrap in response to the
dynamic change, and the inner dark blue absolutely positioned element
remains wrapped at the wrong position when the inner light blue
relatively positioned element rewraps. (I tested this only outside of
the reftest harness, but that should be sufficient.)
I verified manually that the height conditions were correct by modifying
both reftests to add some padding and border to #relpos and margin to
#abspos, changing the height of #abspos so that it was either exactly at
or just above the threshold where reflow was needed, and using
GECKO_DISPLAY_REFLOW_RULES_FILE debugging to verify that the reflow of
the absolutely positioned element did or didn't happen as expected.
MozReview-Commit-ID: 6ISgSEYyMiN
--HG--
extra : transplant_source : %93%86%8Csr_L%83%F2OJ%DC%7F%3D%7D%BC%9C%A6%1F0
IGNORE BAD COMMIT MESSAGES because something landed and was backed out for no bug number
--HG--
extra : amend_source : 1134c379d1134fe160fd2d889488d07acd9f4177
On Windows with webrender disabled and advanced background-color layers enabled,
these tests fail because they have a higer fuzz than allowed. Specifically:
1316719-1a.html -> max difference: 53, number of differing pixels: 785
1316719-1b.html -> max difference: 53, number of differing pixels: 785
1316719-1c.html -> max difference: 53, number of differing pixels: 787
I'm assuming that for now we only care about the advanced background-color layers
when WebRender is enabled, so we can just skip the tests otherwise.
MozReview-Commit-ID: 3HI828mcBdH
Functions like BuildDisplayListForStackingContext or BuildDisplayListForChild look
up EffectSet property several times in callees, such as IsTransformed() or
HasOpacity(), which is time wasting.
We should look up EffectSet just once, and pass the found one to all callees
that need it.
MozReview-Commit-ID: GZywm2UcpU7
--HG--
extra : rebase_source : 21f5dd0076a90d876a6df35eee2b886844b44f0a
FRAME_STATE_BIT of nsFrame and nsINode::mBoolFlags are both full, we need to
find another place to hold MAY_HAVE_OPACITY information.
nsINode::mSlots might be a choice, but since we always use this information in
painting, memory footprint of nsINode will become larger after this change.
So I decide to put this information right in EffectSet. The drawback of storing
this information in EffectSet is, although unnecessary Effect look-up is
prevented, we still need EffectSet property look-up in each time
HasOpacityInternal call, so we need Part 2.
Conceptually, Part 1 and Part 2 are independent.
MozReview-Commit-ID: 6sfBFSHjxQb
--HG--
extra : rebase_source : 394141cec3b44bb352297a0add8f9763d815bddb
Unknown WR cset (WR was broken on LLVMpipe for a big range of changesets, and this
happened somewhere in that range, so it wasn't easy to bisect).
MozReview-Commit-ID: Id5kOdgpK9f
