For those cpp files, it's sufficient to use Corner to refer to
mozilla::Corner.
MozReview-Commit-ID: JmDEJ3gGm8K
--HG--
extra : rebase_source : 79d7fc74fdb827894dd9ea17d6bb382eb75e81e8
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
--HG--
extra : rebase_source : b0a0aad1fec0c2765e96d23ed9b627345c793795
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
--HG--
extra : rebase_source : 080a843b34cc1ca27831310d474243b4066f59f2
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
--HG--
extra : rebase_source : ac80eaea2474b9ec4b47b1cc9a5bdd2e61f6ec4d
We couldn't tell the difference between a null StyleAnimationValue and
transform:none on the compositor. This was not a problem before, since we didn't
need the null StyleAnimationValue on the compositor, because the null
StyleAnimationValue have to be passed with composite:add flag, and in the case of
composite:add we just used the underlying value, i.e. we didn't use the null
value at all.
But for normal additive animations, we have to check the null StyleAnimationValue
to tell whether we are processing a missing keyframe or not.
So in this patch, Animatable can be null_t to represent the null
StyleAnimationValue, and as a result of this change, we can drop
BaseAnimationStyle.
MozReview-Commit-ID: Au41ujHgPpU
--HG--
extra : rebase_source : 71eafcf729e278d2576b9a66bb194c2a7b972f1c
GetImageLayerClip and ComputeImageLayerPositioningArea are used by both
background and mask layer. Rename local variables to reveal this fact.
MozReview-Commit-ID: FjScl95eWJg
--HG--
extra : rebase_source : cad013dabea9af3f5636f894f867ff913d004cce
Test scenario:
1. Hide menu bar
2. Press alt key to make menu bar appear.
3. Without this patch, the poistion of clip-path mask on the tab is not correct.
That is because we do not update mask transform of cached mask.
MozReview-Commit-ID: HPFYPYv7ubB
--HG--
extra : rebase_source : 6584e86a46faaadb9fccbd9fed79da2c58f65a00
After bug 1234485 land, we may create a layer for nsDisplayMask. When we do so,
there is no need of nsDisplayScrollInfoLayer.
MozReview-Commit-ID: KmFYhGKwq92
--HG--
extra : rebase_source : 413628762e2f2c9a951d5c32cd48fbebc750238e
Test scenario:
1. Hide menu bar
2. Press alt key to make menu bar appear.
3. Without this patch, the poistion of clip-path mask on the tab is not correct.
That is because we do not update mask transform of cached mask.
MozReview-Commit-ID: HPFYPYv7ubB
--HG--
extra : rebase_source : ec5aa4a05578a53a9961b86c8804ba53f810c4c4
After bug 1234485 land, we may create a layer for nsDisplayMask. When we do so,
there is no need of nsDisplayScrollInfoLayer.
MozReview-Commit-ID: KmFYhGKwq92
--HG--
extra : rebase_source : 1b42b1435b8ff8515d8919b6789d479a2467f749