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
We need to retrieve the correct base style for Servo backend, so change
the return value to AnimationValue and update
KeyframeEffectReadOnly::BaseStyle().
MozReview-Commit-ID: 9FL3h1DLoJt
--HG--
extra : rebase_source : 42284c5fe8b8135910cde44b0815eb475ca2f1cc
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
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 DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
The telemetry is recorded once per effect:target pair, and is intended for
comparison with the telemetry added in bug 1349808.
MozReview-Commit-ID: 8JYbAifjmki
--HG--
extra : rebase_source : a5adf4ea9c0836d9ad0ecde5e5869d00eccc2205
The telemetry is recorded once per effect:target pair, and is intended for
comparison with the telemetry added in bug 1349808.
MozReview-Commit-ID: 8JYbAifjmki
--HG--
extra : rebase_source : fa0b615684ca1355f9bbc24b3355e90001db47b5
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
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
--HG--
extra : rebase_source : 66c9a9e391c2f9e142575f42fd47b37334ec5752
extra : source : 97a08873177c0f18edffdb1b5589c77843a50553
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
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
Precondition:
In an SVG doc, giving an invalid local-ref mask, e.g. mask="url"#foo"", and
clipState.mDirtyRectInDevPx be empty. e.g. apply mask onto a path object which
the size of area is zero(Please refers to the reftest in Part 2)
1. PaintStyleImageLayerWithSC early continue at [1], and the value of result is
still the initial value, DrawResult::SUCCESS.
2. The caller is not aware of that the mask image was left unresolved since it get
DrawResult::SUCCESS from #1.
This patch fixed this problem by calling PrepareImageLayer before early return
for updating correct drawing result.
[1]
https://hg.mozilla.org/mozilla-central/file/ebf68ba9b098/layout/painting/nsCSSRendering.cpp#l2682
MozReview-Commit-ID: DjJ0Nni1gDl
--HG--
extra : rebase_source : 949101547b6cb4db93c8a889210c768fb81cff7a
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
The origin of a tiled gradient needs to be positioned less than the origin
of its clip bounds, otherwise it won't fill all of its clip bounds. There
is an existing function used by the current code path that can be used to
do this.
MozReview-Commit-ID: 13EtwmZYT4P
--HG--
extra : amend_source : 4fbe6b72efc61b1ef8303422e6e0910970d49fa0
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
Add MOZ_FORMAT_PRINTF to the definitions of PrintAsFormatString in
nsCSSRenderingBorders.h.
MozReview-Commit-ID: 9ZcSgNIPPhM
--HG--
extra : rebase_source : e2c3f86ac58835c0bdaf442f45fee25db99e52a6
nsStyleImage::ComputeActualCropRect may return false under 4 conditions
1. mType is not eStyleImageType_Image.
This function is design to be used when mType is eStyleImageType_Image.
Replace this 'if' check by MOZ_ASSERT.
2. nsStyleImage::GetImageData() returns nullptr
This function will return true if this image refers to a local-ref resource.
3. GetImage returns failure or does not return a valid imgIContainer.
It's possible. Please refers to the comment in imgReqestProxy::GetImage
at [1].
4. imageSize is empty
It's possible too. By giving a malformed image to a style image, we will hit
this condition. And this is right what we met in this bug.
Since ComputeActualCropRect may actaully return false, we should remove the
NS_ASSERTION that assume it will always return true.
[1]
https://hg.mozilla.org/mozilla-central/file/7f1f1559cd8d/image/imgRequestProxy.cpp#l513
MozReview-Commit-ID: KHTFQJjiLtT
--HG--
extra : rebase_source : c4e119dd250094115ab23c323ca49f9ebc296698
Fixed backgrounds were not being clipped correctly when rendered using
inactive layers.
MozReview-Commit-ID: 3v8tajr3MoB
--HG--
extra : rebase_source : 25329cb9efb998c64924916d4ea496a439688c8d
We will use this later in this patch series to simplify the creation of SMIL's
ValueWrapper objects.
MozReview-Commit-ID: 7EF9CN2SdwQ
--HG--
extra : rebase_source : e7cf5adc4c3f72dcc4b99625a8d0cb1a2d17f7d4
In nsCSSRendering::PaintBorderWithStyleBorder:
DrawResult
nsCSSRendering::PaintBorderWithStyleBorder()
{
if (aStyleBorder.IsBorderImageLoaded()) {
(1)
}
(2)
}
At (1), we create a nsCSSBorderImageRenderer object. While creating it, we call
imgRenderer.PrepareImage() to ensure a full image decode at [1]. PrepareImage is
used in both bg-image/mask-image and border-image. The difference is, in
bg-image/mask-image painting path, we unconditionally use PrepareImage(in
nsCSSRendering::PrepareImageLayer), whereas in border-image painting path we
use it only after border-image was downloaded. This difference does cause a
problem. After border image was downloaded, the decoder will not do full decoding
since we did not ask for it, so there will be no repaint notification and no
chance to paint border-image again.
In this patch, I try to align the behavior between bg-image/mask-image and
border-image: always call nsImageRenderer::PrepareImage.
This is a generic fix for both stylo-enable and stylo-disable build. We do not
find this problem in reftest is because we use SYNC_DECODE in reftest harness, which
hides this race condition. When daily using firefox, if
nsCSSRendering::PaintBorderWithStyleBorder is called after border-image was
loaded, your program run into (1), border-image will be drawn correctly; In the
case that nsCSSRendering::PaintBorderWithStyleBorder is called before
border-image is loaded, your program run into (2), and you can only see
border-color.
[1]
https://hg.mozilla.org/mozilla-central/file/a6f35285bd1e/layout/painting/nsCSSRenderingBorders.cpp#l3598
MozReview-Commit-ID: 6pidHJdPG8I
--HG--
extra : rebase_source : 2be402f59a42ef767ab6bae2962cd2ec55b36c50
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
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
In nsCSSRenderingGradients the logic for handling many error conditions
and normalizing the gradient stops is shared between the paint path and
the WebRender path. WebRender now normalizes gradients and handles any
error conditions that it needs to. There are some conditions that are not
problems for it, like repeating radial gradients with stops below zero.
This commit undoes the work done in bug 1341101 to share this logic. Some
conditions were moved around in bug 1341101 to make things simpler, and
that has been undone. Now the paint path is identical to how it was
originally.
There is one exception, which is ResolveMidpoints which is kept between
both code paths. This should be safe.
MozReview-Commit-ID: LMhMNXNquXM
--HG--
extra : rebase_source : 2d389f76134671b6caa44a3b7370b1c786576bdc
extra : histedit_source : caf5d3a456cbb9987970783969d0eb2a424e7eca
LayerActivityTracker::NotifyExpired() will be invoked by
nsExpirationTracker::TimerCallback() from an unlabeled runnable.
We provide a SystemGroup EventTarget for the invocation of this
callback since there's nothing within a page that would rely on
the timer firing at a particular time (i.e., it doesn't matter
when this timer's callback is scheduled, relative to other
runnables dispatched for the page).
MozReview-Commit-ID: FZHtqicwDG5
--HG--
extra : rebase_source : 741983a64e7b9835999bdb344bc5f163eebac246
We will obsolete StyleAnimationValue in the future, and can treat
AnimationValue as a wrapper of RawServoAnimationValue to hide the FFIs
at that moment. For now, we still need both types, so it's better to make sure
they are mutually exclusive in AnimationValue. Therefore, let's add some
assertions.
Besides, I think those FFIs might do many things and it seems those methods
are not critical, so let's move them into the cpp file, so we can remove
some dependencies to avoid re-compiling so many files if someone needs
revise ServoBindings.h.
MozReview-Commit-ID: FJ1uTvEQ7NT
--HG--
extra : rebase_source : 8ef99c659f2721c8425364051db19b66536bccc6
This switches over layout's usage of PLArena to ArenaAllocator. This allows
us to build more files in unified sources and gets rid of various CONST masks.
MozReview-Commit-ID: Aaf3Dl2kaoz
Refactor the existing PaintGradient method into a nsCSSGradientRenderer class. The purpose
of this is to separate the calculation of gradient parameters from the painting of the
gradients. This should help us to share code between WebRender and our existing
painting code. It does not change how we render gradients currently.
MozReview-Commit-ID: 4P8vPqK4V8g
--HG--
extra : rebase_source : 031cd8d15148153b0af23fa9ff0abbf037d028db
Mats Palmgren
Botond Ballo
Markus Stange
Sebastian Hengst
Andrew Osmond
Matt Woodrow
Alexis Beingessner
Nicholas Nethercote
Jeff Hajewski
Ryan VanderMeulen
Martin Robinson
L. David Baron
Martin Robinson
Jared Wein
Wes Kocher
Miko Mynttinen
Kartikaya Gupta
Mason Chang
Ryan Hunt
Morris Tseng
Jonathan Kew
cku
Carsten "Tomcat" Book
Boris Chiou
Ethan Lin
Iris Hsiao
Bas Schouten
peter chang
Brian Birtles
Emilio Cobos Álvarez
Phil Ringnalda
Tom Tromey
Jamie Nicol
Chris Peterson
Astley Chen
Michael Layzell
Brad Werth
sotaro
David Anderson
Jeremy Chen
Hiroyuki Ikezoe
Nazım Can Altınova
Eric Rahm
Thinker K.F. Li