As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
Let's said we have a div,
<div id="outer" style="width:200px, height:200px;
mask="url(opaque-200X100-transparent-200X100.png)"">
<div id="innter" style="position:fixed;
left:0px; top:0px; width:200px; height:100px;
mask-repeat: no-repeat;
background-color: blue;"></div>
</div>
Some hints:
1. '#inner' is out-of-flow
2. '#outer' itself does not draw any things, no background/ border, etc....
3. Mask applied on '#outer'.
4. opaque-100X200-transparent-100X200.png is a 200X200 image. The upper side of
this image is opaque; the lower side of this image is transparent.
After page load, you will see a 200X100 blue rect on left-top corner. This blue
rect is contributed by 200X100 blue '#inner' and 200X100 opaque upper part of
mask. So far so good.
Then you scroll down 100px. '#inner' is not moved, since it's an out-of-flow
element, mask move up 100px with '#outter'. Ideally, you should see nothing in
the view, since '#inner' is now masked by transparent part of the image mask.
On FF, you will still see a 200X100 blue rect in view as if no scrolling at all,
which is wrong.
Here is the root cause of this bug:
1. At beginning, we create a 200X100 mask layer, which fit the size of '#inner'.
Not 200X200 of '#outer', since '#outer' basically draw nothing, we smartly
choose a more compact draw target for painting the mask.
2. Things go wrong after scrolling down. By scroll down 100px, the size of the
mask layer is still "200X100", so we _think_ cached mask layer is still
reusable, but it is not.
Before scrolling, we paint (0, 0, 200, 100) portion of the 200X200 mask onto
mask layer; after scrolling, we should paint (0, _100_, 200, 100) portion of
mask onto mask layer. We did not keep this kind of offset information in
CSSMaskLayerUserData, so we don't know that the cached mask layer should be
rejected.
It's difficult to create a reftest for this bug as well. With scrollTo, we may
mimic an environment of this error, but since reftest harness will trigger
whole viewport repaint while taking a snapshot, we actually can not repro this
issue on it.
MozReview-Commit-ID: H5xaUSssMRh
--HG--
extra : rebase_source : 47103b6638e50dd2fb39f7b47e9cdc653446cd20
Remove HasUserSpaceOnUseUnitsMaskOrClipPath since it's not necessary.
MozReview-Commit-ID: 2sen23m5GjE
--HG--
extra : rebase_source : fe15fc807daf79f6f2175224928a1d83736cf85b
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
--HG--
extra : rebase_source : 696bf495edc98a390f49ff0638165724521460b1
extra : source : 95f38c2c8b57134504e7fbe03d1637866e3e65ba
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or to call a function for side effects within an expression. In addition to fixing the warnings, replace some char16_t(' ') casts of char literals with shorter UTF-16 character literals u' '.
layout/painting/FrameLayerBuilder.cpp:3647:31 [-Wcomma] possible misuse of comma operator here
layout/painting/FrameLayerBuilder.cpp:3657:41 [-Wcomma] possible misuse of comma operator here
layout/painting/nsCSSRenderingBorders.cpp:3336:33 [-Wcomma] possible misuse of comma operator here
layout/painting/nsCSSRenderingBorders.cpp:3336:60 [-Wcomma] possible misuse of comma operator here
layout/painting/nsCSSRenderingBorders.cpp:3337:33 [-Wcomma] possible misuse of comma operator here
layout/painting/nsCSSRenderingBorders.cpp:3337:60 [-Wcomma] possible misuse of comma operator here
layout/style/Declaration.cpp:808:41 [-Wcomma] possible misuse of comma operator here
layout/style/Declaration.cpp:812:42 [-Wcomma] possible misuse of comma operator here
layout/style/FontFaceSet.cpp:1118:60 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: 9tfcIsnnBwM
--HG--
extra : rebase_source : 89916d1d7b43e4c4793364637a8d015242cb033f
extra : source : c5921d4d63f8f68eafe5a33013e08f9a455429d9
If a painted layer would previously only contain an event regions item, we
would not associate that item with any cached layer. As a result we would
generate a new, empty, invisible painted layer each frame. This is disastrous
on large layer trees as it can cause many needless repositions. Instead, we
make sure to accumulate the invisible item.
