This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 98da45bc7f2eaabd63ae226c505cb1580b5c8500
Instead of just keeping a count of how many "extra clips" (aka
out-of-band clips) we have pushed, track more complex information for
each clip. In particular, track the display item's normal clip chain, as
well as the clip id of the extra clip that was pushed. This will be
needed to override clip cache information in the next patch.
MozReview-Commit-ID: AWKDTkelhyL
--HG--
extra : rebase_source : 379e38550cf45d54862850f6c4aad0ac488f6ca9
2017-10-24 15:45:59 -04:00
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
Also explicitly disables the image-border and gradient-border cases,
which were already accidentally disabled. They are too bitrotted to turn
back on at the moment.
MozReview-Commit-ID: FRXqemXQHJN
--HG--
extra : rebase_source : 497ef792d64b1f9911ce5d969667947917989da1
In nsCSSRendering::PaintStyleImageLayerWithSC, we reuse the same clip-state
object, clipState, for all bg/mask layers. We hit this assertion if the
border-radius of previous one is not 0, but the the border-radius of the next
one is 0. In this condition, clipState.mHasRoundedCorners is false, but
clipState.mClippedRadii still stores border-radius information of the previous
layer.
MozReview-Commit-ID: KyxD0vPnMb9
--HG--
extra : rebase_source : 198c916c35ecd51a72dc3df83df43d6dc5f6424c
extra : source : e630c34a8b6397a3e8a08e57d400accff392e25f
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget
hack. The old design had several limitations:
* It couldn't handle shadows
* It couldn't handle selections
* It couldn't handle font/color changes in a single text-run
* It couldn't handle decorations (underline, overline, line-through)
Mostly this was a consequence of the fact that it only modified the start and end
of the rendering algorithm, and therefore couldn't distinguish draw calls for different
parts of the text.
This new design is based on a similar principle as DrawTargetCapture, but also passes
down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can
notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us
directly pass data to TextDrawTarget when possible (as is done for shadows and selections).
In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle
changes in font/color mid-text-run (which can happen because of font fallback).
The end result is:
* We handle all shadows natively
* We handle all selections natively
* We handle all decorations natively
* We handle font/color changes in a single text-run
* Although we still hackily intercept draw calls
* But we don't need to buffer commands, reducing total memcopies
In addition, this change integrates webrender's PushTextShadow and PushLine APIs,
which were designed for this use case. This is only done in the layerless path;
WebrenderTextLayer continues to be semantically limited, as we aren't actively
maintaining non-layers-free webrender anymore.
This also doesn't modify TextLayers, to minimize churn. In theory they can be
augmented to support the richer semantics that TextDrawTarget has, but there's
little motivation since the API is largely unused with this change.
MozReview-Commit-ID: 4IjTsSW335h
--HG--
extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
Before bug 929484, border-radius on row groups, rows, column groups,
or columns don't apply to the background of each cell, yet the
border-radius on the cell itself does. After bug 929484, the behaviors
changed. In this patch, I tried to revert the behaviors of border-radius
on table row groups, rows, column groups, or columns back to
what happened before bug 929484.
MozReview-Commit-ID: 1Xg1qHde3lk
--HG--
extra : rebase_source : ff08f8390ff910fe8c141a75275134f77a1cec3e
We overwrites DrawResult returning from
nsCSSBorderImageRenderer::CreateBorderImageRenderer by the returning value of
DrawBorderImage, which is not right.
MozReview-Commit-ID: 1EeqU5hLyln
--HG--
extra : rebase_source : a78aa841795afa830b66da650a619f46230b10dd
Remove the the duplicate check for draw background image is false, in the PaintStyleImageLayerWithSC method,
as this is already covered by the preceding code.
MozReview-Commit-ID: L669Y4OjzE0
--HG--
extra : rebase_source : 1cd5d7bcfb5a268486c8a898864cc60fda9d70a7
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
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
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
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 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 avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
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
A few includes and namespace annotations are missing. And
nsImageRenderer.cpp is calling two functions that are static functions in
nsCSSRendering.cpp.
MozReview-Commit-ID: BLVPwpKB7On
--HG--
extra : rebase_source : d6111d093de47b88b5beba6478de4b6ed75b2a52
This function is not a virtual function and always returns CAIRO_STATUS_SUCCESS
after the patch in bug 1054838 landed. There is no reason to keep it anymore.
MozReview-Commit-ID: EadrrFQyjfY
--HG--
extra : rebase_source : 3f6a284dc9fa396d5cfd3f64190562373801a0a2
This change is to use gecko_enum_prefix in helpers.mako.rs, so that we do not
need to manually write code for nsStyleDisplay::mTransformBox.
MozReview-Commit-ID: 7UAL0iUcSIO
--HG--
extra : rebase_source : e99b7c163991df7ef3e7c0404fcef1832718a150
If mask-mode is luminace, we will create a temporary context at [1]. It's
obvious we do not use this gfxContext at all in PaintGradient path. This patch is
trying to fix this problem by pass gfxContext, instead of RenderingContext,
directly to PaintGraident.
[1] https://hg.mozilla.org/mozilla-central/file/991f5724e58f/layout/painting/nsCSSRendering.cpp#l5811
MozReview-Commit-ID: LLmg4k6IEm3
--HG--
extra : rebase_source : ed42e3f5ddf1314300259c3f74d43aac8b4683de
There is no direct relation between this patch and the bug. Read through the code
and think we may reuse some logic.
MozReview-Commit-ID: HGEvDNGoIBS
--HG--
extra : rebase_source : b349702a787203317c6e66be0b9aa6818d532788
extra : source : b4ca22d03b6ba3e8eb9d0e3551830149ec99de82
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
With the ActiveScrolledRoot changes, we will need to set up different state on
the display list builder prior to creating the nsDisplayBackgroundImage item.
MozReview-Commit-ID: CgeffVPccfj
--HG--
extra : rebase_source : e2e1481a2e9df8becf56b969f151915694d62a8d
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
Ethan Lin
Kartikaya Gupta
Daniel Holbert
Alexis Beingessner
Attila Craciun
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
Jonathan Kew
cku
Sebastian Hengst
Morris Tseng
Nicolas Silva
Jonathan Watt
Ya-Chieh Wu
Xidorn Quan
Carsten "Tomcat" Book
Wes Kocher
Mason Chang
Michael Scott
Nicholas Nethercote
Andi-Bogdan Postelnicu
Jeff Hajewski
L. David Baron
Ryan VanderMeulen
Mats Palmgren
Emilio Cobos Álvarez
Markus Stange
Ryan Hunt
Gajanan
Mantaroh Yoshinaga
Ting-Yu Lin
Phil Ringnalda