The spec said:
The generated instance of a ‘symbol’ that is the direct referenced element of a
‘use’ element must always have a computed value of inline for the display
property. In other words, it must be rendered whenever the host ‘use’ element is
rendered.
We use -moz-use-shadow-tree-root pseudo class to achieve this requirement.
MozReview-Commit-ID: 1ReJjmjxq6G
--HG--
extra : rebase_source : b4d267792dd6d69f7d5336c5ed33a0fc60e97b9e
Since we already have nsSVGSymbolFrame, there is no need to leverage svg element
for rendering symbol element in use-element shadow tree, remove conversion code.
MozReview-Commit-ID: GmGLZ7Az6Gb
--HG--
extra : rebase_source : 897a1fb7b34bb3aa3babe99b7199e7f002d59e6b
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
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
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 that this commit fixes
nsSVGPaintServerFrame::GetPaintServerPattern rather than PaintSVG.
Commit-ID: 691YrKZ0Lm9
MozReview-Commit-ID: KSnFhCndFUk
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 primary patch in bug 1308876 causes frames to be reflowed less often
with NS_FRAME_IS_DIRTY, particularly when multiple passes of reflow are
required for the frame or one of its ancestors (which is generally the
case for a document that ends up not having scrollbars). This change
causes this assert to fire on various SVG tests such as
layout/reftests/svg/svg-integration/conditions-outer-svg-01.xhtml .
This happens because the outer SVG with conditional processing (in this
test, systemLanguage="x") is reflowed due to its parent resizing,
without NS_FRAME_IS_DIRTY set. This is a relatively normal thing to
happen during reflow; we just didn't have any tests that exercise it.
This patch adds a crashtest that triggers the assertion through the same
mechanism, but with a dynamic change, rather than depending on the
non-dirty reflow triggered by bug 1308876. (I confirmed locally that
this test does trigger the assertion without this patch, when run in the
crashtest harness.)
I think fundamentally the assertion isn't valid, and we should instead
be testing the condition that it asserts.
MozReview-Commit-ID: D8hjAbjKyuL
--HG--
extra : transplant_source : %98C%3A%B1%93jb%E7%3D%81%19%97%A6%04%0F%88%8B%D2%A35
The reason of this change is the same as for Part 2, except that this commit fixes
nsSVGPaintServerFrame::GetPaintServerPattern rather than PaintSVG.
Commit-ID: 691YrKZ0Lm9
MozReview-Commit-ID: KSnFhCndFUk
--HG--
extra : rebase_source : 3397613129fff6023833cdc3bd639f0d2b151652
extra : source : fa29f1920a88d88bcf0f5239462d32ee8955895c
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
GetPreEffectsVisualOverflowRect is a function that be used in both reflowing
and painting. PreEffectsBBoxProperty of continuations is not set correctly yet
in reflow process, so we should skip this assertion check during reflow.
PS:
I will change MOZ_ASSERT, in GetPreEffectsVisualOverflowRect, back to NS_ASSERTION
if we still encounter this assertion in the future.
MozReview-Commit-ID: 6Gvg3XOd2mD
--HG--
extra : rebase_source : 88f605dc3aa2fd63fbe60925c0a21cc370ff3b6b
extra : amend_source : 0fb6a36486d7a96546e3362393d8501744ebdc34
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
ResolveURLUsingLocalRef is designed to be internally used by
nsSVGEffects::Get-{SVGEffect}-URI functions. Since we also need it in
SVGUseElement::LookupHref, make it public in nsSVGEffects.
MozReview-Commit-ID: Hsvs8Uzahrz
--HG--
extra : rebase_source : 54698a477a2ebb3f635fb3a77f6bc39b1741b05b
Now, remove Layer::mSourceURI, there are several benefit of doing this:
1. Reduce the size of nsStyleImage::Layer.
2. By storing style image and url information in nsStyleImage, we can remove
many verbose comments. That is becasue there is no need to explain why we use
mSourceURI here, or why we use nsStyleImage there anymore.
3. Since all inforamtion is stored in on place, nsStyleImage, we can setup image
request or URLs by one single Gecko_SetUrlImageValue call.
MozReview-Commit-ID: 7aTQobddTB1
--HG--
extra : rebase_source : 247e3b66c727a9116c58d3d6ff3ae0f7a58f2338
Previously if an outer-<svg> had children-only transforms we would create
an nsDisplayTransform display list item for every child of the <svg> element.
For certain SVG files this could cause performance problems. This commit makes
us create a single nsDisplayTransform for the nsSVGOuterSVGFrame's anonymous
child frame rathen than one nsDisplayTransform for every real child.
Add one paramater to nsSVGDisplayableFrame::PaintSVG, so that we can pass
sync-decode flag from nsXXXXDisplayItem::Paint function to SVG paint call.
MozReview-Commit-ID: 6VZbxnFaoUj
--HG--
extra : rebase_source : c55e457e0d7a81b4a574d970924e0af6f7a7db48
According to bug 1345853 comment 5, tn said:
You probably want to return whatever was drawn there regardless of the
DrawResult. SVGMaskFrame has the same problem. Keep in mind that DrawResult is
only reporting on how drawing of any images went, not the drawing of anything
else. Also looking over the patches from bug 1258510 I see a couple places where
BAD_ARGS is returned if the transform matrix is singular. We would want to
return SUCCESS in that case I think, because we drew what we were instructed to
draw.
MozReview-Commit-ID: 5XcDuKQwXTJ
--HG--
extra : rebase_source : 5c558d469148e0cb3cfe9365aed1a4a65c572532
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : ca7a35bb9f5e27880d5dc62e03feb91b6ac3435d
This change makes SVGEmbeddingContextPaint's GetFillPattern and
GetStrokePattern methods honor their opacity arguments as they should. Since
these arguments must affect the gfxPattern that is returned, the code now
creates those on demand rather than creating them up front and caching them.
MozReview-Commit-ID: 4oemU2nRMeQ
Implement this unil function to improve readability
MozReview-Commit-ID: FLKOGyq180W
--HG--
extra : rebase_source : db8dbc67dbc63c19df806e79ea36016d3d5fc8b6
extra : source : 47fa0a1f03acd6007e2d40e4ec5bc0ddba221361
This is a bug from https://hg.mozilla.org/mozilla-central/rev/2d171d75b746 (bug 1157546). It took a shortcut in trying to get around one of the downsides of tracking visibility on frames instead of content nodes.
We cannot get our primary frame during FrameCreate calls because FrameCreate is called during the frame's Init() function, which happens before the primary frame pointer is set.
So when TrackImage is called from FrameCreate |frame| will be null but mFrameCreateCalled will be true. So we won't hit the early return that tries to detect nonvisible images.
The comment being removed is just wrong. We can obtain a frame for <feImage> just as well as any other image type.
The thing that is different about <feImage> is that it calls IncApproximateVisibleCount() followed by FrameCreated() in the frame's Init() function. This means that the frame is marked visible at the time of the FrameCreated, and there will be no further calls to TrackImage (because there are no further changes). So the FrameCreated call is the last chance to mark this image visible. The regressing changeset tries to get around this by just considering the image visible whenever we know a frame exists (because of mFrameCreateCalled) but can't access it. This ends up affecting all types of images, not just <feImage>.
The above paragraph is also true for SVG <image> that are non-display.
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
According to bug 1345853 comment 5, tn said:
You probably want to return whatever was drawn there regardless of the
DrawResult. SVGMaskFrame has the same problem. Keep in mind that DrawResult is
only reporting on how drawing of any images went, not the drawing of anything
else. Also looking over the patches from bug 1258510 I see a couple places where
BAD_ARGS is returned if the transform matrix is singular. We would want to
return SUCCESS in that case I think, because we drew what we were instructed to
draw.
MozReview-Commit-ID: 5XcDuKQwXTJ
--HG--
extra : rebase_source : ba764df599844c9eb179736f61d6c7f6ee46c9fc
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : bc338b1a33f1dbf209706577b2455315dfb855e2
This change fixes the code so that it does not assume that frames with the
NS_FRAME_SVG_LAYOUT bit set implement nsISVGChildFrame. This assumption is
incorrect since there are many SVG frame types that do not inherit
nsISVGChildFrame (such as nsSVGGradientFrame).
MozReview-Commit-ID: 9dCZAhJk3E0
--HG--
extra : rebase_source : 346755b3215b38560ab57e87cf12585b4a869d65
I introduced ComputeTargetBBoxInFilterSpace[1] function in bug 1287492.
Two reasons that I think we should not clip filter boundary by viewport
in that function:
1. The patch in bug 1336480 can also fix bug 1287492 and is more correct.
2. That restriction cause wrong rendering result
In this bug, reporter apply filter onto a path object in pattern element.
Before the clipping applied in [1], the boundary of filter effects region is
(x=-1, y=-1, width=10, height=10) in CSS units
After clipping by svg viewport, the boundary turns out to be
(x=0, y=0, width=9, height=9) in CSS units
which is smaller then we need for filter painting. So we should stop clip the
boundary by svg viewport. (Please refer to filter-in-pattern-02.svg in the next
patch).
[1] https://hg.mozilla.org/mozilla-central/file/dbabc189256e/layout/svg/nsFilterInstance.cpp#l235
MozReview-Commit-ID: 2d14rnyWPJs
--HG--
extra : rebase_source : ca3a523c8ae95d166441690d5ee1def2ed56a550
There are two places that use nsFilterInstance::PaintFilteredFrame. One is
nsSVGIntegrationUtil::PaintFilter, we do take care of it in bug 1224207.
Another path is at nsSVGUtils::PaintFrameWithEffects, apparently I missed that
path while working on bug 1224207.
MozReview-Commit-ID: K4MjKa4ZpCR
--HG--
extra : rebase_source : 46696b620b210348052fe554b15abf0c3adedc72
