This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
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