This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
Activate WebRender output for filters that introduce only one pixel
differences in tests. Since the filters spec does not seem to specify
how color values are rounded, this output should be spec compliant.
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
