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
Specifically:
- SVGGeometryFrame.cpp has several uses the type SVGGeometryElement which is
really mozilla::dom::SVGGeometryElement. So I'm adding a 'using' decl for
the 'mozilla::dom' namespace (and I'm dropping a now-unnecessary explicit
dom:: prefix from another type there).
- SVGImageContext.cpp calls several functions on nsIFrame (PresContext() &
StyleSVG() at least). So I'm adding an #include for nsIFrame.h.
- nsSVGMarkerFrame.cpp uses the type SVGGeometryFrame, which is really
mozilla::SVGGeometryFrame. So I'm adding a 'using' decl for
the 'mozilla' namespace.
MozReview-Commit-ID: AlCrocHhPtr
--HG--
extra : rebase_source : 8fe64f35179954813c00188587e0d7724f17791c
These only build successfully (in unified mode) right now because they're lucky
enough to pick up a "using namespace mozilla;" declaration from a .cpp file
earlier in their unified compilation unit.
MozReview-Commit-ID: JylaTtjdSZu
--HG--
extra : rebase_source : 5233e0322556f2494745fa6ece6ea0fd6af23fec
SVG <image> elements have approximately the same level of visibility tracking as regular html <img>s so we shouldn't need to do sync decode. It shows up in some profiles.
The comment being removed was written a long time ago, before image visibility tracking for one.
We could even go a step further and ask for no sync decoding at all, but one step at a time to make sure this doesn't cause any regressions.
This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
--HG--
extra : rebase_source : 3119776946dc2c8350098b7bf9f3ceff29bdffb5
There is no need to limit output space bounds in
nsFilterInstance::OutputFilterSpaceBounds(), it's just far too early.
MozReview-Commit-ID: 9i9huKDGxq6
--HG--
extra : rebase_source : 3f7a16fe27f661e79087c6a302235b01f65169d5
For a table, the primary frame is the table wrapper anonymous box. That
anonymous box inherits style from its _child_ table frame, which is the frame that
has the actual style for the element. So we want to use the stylo-computed
style for the table frame, and then compute an updated style for the table
wrapper too, because some things (like absolute positioning) are done for the
table wrapper anonymous box, not the table frame.
Except during restyle process, we should skip this checking in reflow as well.
But what really should do is to skip this checking if this function is called
from ComputeEffectsRect. The reason is explained in the beginning of
ComputePostEffectsVisualOverflowRect.
Also promote NS_ASSERTION to MOZ_ASSERTION in this patch.
MozReview-Commit-ID: 3CuKkdR4kTK
--HG--
extra : rebase_source : 968f708603ec4424dd32f23bf2a4ffc74ce3fc85
1.
mUserSpaceBounds & GetFilterSpaceBounds are not used at all. This patch is
simply removing mUserSpaceBounds and codes relative to them.
2.
GetFilterSpaceBounds is defined but not used. Remove.
MozReview-Commit-ID: 7vJmZP4jC5F
--HG--
extra : rebase_source : 6798c938a4e3b1ab513dcc3b3f6da293fda45e1f
According to jwatt's suggestion, rename back to original name.
MozReview-Commit-ID: 8dUo7ZWoac6
--HG--
extra : rebase_source : 0beb263ca4c99597661da37dca14943637fd4e9e
After fighting with this assertion several months, I decided to remove it for
two reasons:
This assertion allows PreEffectBBoxProperty not being cached only under specific
condition. But the condition is wider then we expect.
1.
PreEffectsBBoxProperty is cached by nsIFrame::FinishAndStoreOverflow(this
function calls ComputeEffectsRect which cache this property actually) and
it is called from nsXXXFrame::Reflow on demand. Yes, *on demand*, not always.
And this is the fist reason that why I think we should just remove
this assertion.
For example, nsBlockFrame::Reflow calls FinishAndStoreOverflow to store this
property. But like BRFrame, it does not call FinishAndStoreOverflow at all.
In anohter word, if you apply any SVG effect to a BRFrame, you will always hit
this assertion. Here is an example:
<br style="filter: saturate(0%);"/>
So, if we still want to keep this assertion, we may need to create a list which
list all frame types that cache PreEffectsBBoxProperty, and do this check only if
the type of aFrame is listed. This is error prone since we may introduce a
new frame type at any time and forget to update this table.
2.
So, I think it's better just removing this assertion. The assertion that we
really need is the next one(2nd one):
MOZ_ASSERT(!preTransformOverflows,
"GetVisualOverflowRect() won't return the pre-effects rect!");
Since hitting that assertion, the 2nd one, means caller will retrieve wrong
effect region. Hitting the first assertion only means we do not cache
PreEffectsBBoxProperty, it's pretty normal and not hurt anything. This is the
second reason that I think we should remvoe this assertion.
MozReview-Commit-ID: JfiYTiP2laG
--HG--
extra : rebase_source : b0225e36cd7e33a23516cfbe5a40c731d92f8825
Clip mTargetBBoxInFilterSpace by the bounds of parent SVG frame. Fix this bug and
good for both rendering performance and memory consumption.
The root cause of this bug
<svg width="100" height="100" style="filter: opacity(100%);">
<g transform="matrix(200,0,0,200,-20000,-20000)">
<rect width="200" height="200" style="fill:lime">
</g>
</svg>
In this example, <rect> is going to be a huge graphic object because of the scale
transform in <g>. The bounding-box of <svg> is an union of all descedants, so the
size of mTargetBBoxInFilterSpace is huage too. We are not able to create such a
huge surface because of the limitation at
nsFilterInstance::OutputFilterSpaceBounds[1].
[1] https://hg.mozilla.org/mozilla-central/file/f4f6790e3926/layout/svg/nsFilterInstance.cpp#l556
MozReview-Commit-ID: 4Fdj5mgcE0V
--HG--
extra : rebase_source : 00b668933255cc9ea4a5f5e4fddc6d2f509c41c7
GetNearestSVGViewport is not used anymore, rewrite it, Part 3 will need this new
version.
MozReview-Commit-ID: GNJXICG9akj
--HG--
extra : rebase_source : 7498404cdafca7563ad93d685efac7c606a7ff0b
The biggest change is located in
nsFilterInstance::ComputeUserSpaceToFilterSpaceScale.
Originally, nsSVGUtils::GetCanvasTM is used. This function returns combination
of svg-transform, e.g. <rect transform="translate(30,40)" />, and
css-to-dev-scale-transform. That why we do not see this bug in a transformed
svg element.
For example, the following svg can be rendered correctly on FF:
<svg xmlns="http://www.w3.org/2000/svg">
<defs>
<filter id="blurMe">
<feGaussianBlur in="SourceGraphic" stdDeviation="1"/>
</filter>
</defs>
<!-- nsSVGUtils::GetCanvasTM return transform="scale(3)" correctly -->
<text x="0" y="35" font-size="35" transform="scale(3)" filter="url(#blurMe)">
Hello, out there
</text>
</svg>
Unfortunately, this function does not report css-transform at all. So, I
replaced it by mPaintTransfom, which is passed from the caller. So now it's the
caller's responsibility to pass a UserSpace-To-DeviceSpace transform into
nsFilterInstance. And, we actually change the meaning of mPaintTransform in this
patch. Before this patch, mPaintTransform means css-to-dev-px scaling transform;
After this patch it means "userspace-to-filterspace-scaling * css-to-dev-scaling"
transform.
All the other modifictions are to respect the change in
nsFilterInstance::ComputeUserSpaceToFilterSpaceScale.
MozReview-Commit-ID: LwNUAMo98M
--HG--
extra : rebase_source : 4ed9fbd1493decef43b6d606d78c4dd23e975146
To use GetCSSPxToDevPxMatrix in nsFilterInstance, pull this untility function down
to nsSVGUtils; Otherwise, we have to include nsSVGIntegrationUtils header in
nsFilterIntance, which is ok but not good I think.
MozReview-Commit-ID: 6SGtwj4EE1S
--HG--
extra : rebase_source : f75c904602f7f0f4ad0e4bdb5786c3a405a86be6
1. Rename gfx->sourceCtx.
2. Since sourceCtx is discarded immidiately, there is no need of save/restore.
MozReview-Commit-ID: CM2MMBYWp3W
--HG--
extra : rebase_source : e9e2b92ac08a41da4e6f9a40886f329e8aa0fc29
1. Pass offset in device pixel unit instead of app unit.
2. Keep old context of the basic manager before replacing.
MozReview-Commit-ID: IoYFTU35aw6
--HG--
extra : rebase_source : b77c8e32d875fe69838904932e47bbee161c987a
We need ComputeEffectOffset along in the following patch.
MozReview-Commit-ID: GoIZ07IqoQ3
--HG--
extra : rebase_source : 54ad8ad25225a110b1cdf190d51df771386b7a26
The biggest change is located in
nsFilterInstance::ComputeUserSpaceToFilterSpaceScale.
Originally, nsSVGUtils::GetCanvasTM is used. This function returns combination
of svg-transform, e.g. <rect transform="translate(30,40)" />, and
css-to-dev-scale-transform. That why we do not see this bug in a transformed
svg element.
For example, the following svg can be rendered correctly on FF:
<svg xmlns="http://www.w3.org/2000/svg">
<defs>
<filter id="blurMe">
<feGaussianBlur in="SourceGraphic" stdDeviation="1"/>
</filter>
</defs>
<!-- nsSVGUtils::GetCanvasTM return transform="scale(3)" correctly -->
<text x="0" y="35" font-size="35" transform="scale(3)" filter="url(#blurMe)">
Hello, out there
</text>
</svg>
Unfortunately, this function does not report css-transform at all. So, I
replaced it by mPaintTransfom, which is passed from the caller. So now it's the
caller's responsibility to pass a UserSpace-To-DeviceSpace transform into
nsFilterInstance. And, we actually change the meaning of mPaintTransform in this
patch. Before this patch, mPaintTransform means css-to-dev-px scaling transform;
After this patch it means "userspace-to-filterspace-scaling * css-to-dev-scaling"
transform.
All the other modifictions are to respect the change in
nsFilterInstance::ComputeUserSpaceToFilterSpaceScale.
MozReview-Commit-ID: LwNUAMo98M
--HG--
extra : rebase_source : eaae0570dcc0b8dea39f5d4b87f5e2920509053d
To use GetCSSPxToDevPxMatrix in nsFilterInstance, pull this untility function down
to nsSVGUtils; Otherwise, we have to include nsSVGIntegrationUtils header in
nsFilterIntance, which is ok but not good I think.
MozReview-Commit-ID: 6SGtwj4EE1S
--HG--
extra : rebase_source : ff6c6173c599afe630aa8b16330a0d1fc667ced8
1. Rename gfx->sourceCtx.
2. Since sourceCtx is discarded immidiately, there is no need of save/restore.
MozReview-Commit-ID: CM2MMBYWp3W
--HG--
extra : rebase_source : 059f205b65632984cfaed535348ae702501d10d8
1. Pass offset in device pixel unit instead of app unit.
2. Keep old context of the basic manager before replacing.
MozReview-Commit-ID: IoYFTU35aw6
--HG--
extra : rebase_source : 03c3b70c2c7f93acd1654fd4eefba602bfa2974d
We need ComputeEffectOffset along in the following patch.
MozReview-Commit-ID: GoIZ07IqoQ3
--HG--
extra : rebase_source : d8750a067e436912643f351737d0bdb392036c50
Prior to this patch whenever we wanted to pass on a modified SVGImageContext
we would pass on a new object initialized with some of the data of the object
we were given and with the new data we wanted to change. Unfortunately we
were sometimes failing to faithfully copy member data that we do not want
to modify (because of default arguments). This patch fixes that by making us
fully copy the object we were given using its copy constructor and then
explicitly override the data we want to change.
For nsSVGUtils::FrameSpaceInCSSPxToUserSpace:
If we give a nsSVGUseFrame to this function, it will return <use>'s x/y as
translation vector, which is not necessary. A point (a, b) in frame's
coordinate space should keep (a, b) in <use>'s coordinate space with no change.
Since we remove extra translation in nsSVGUtils::FrameSpaceInCSSPxToUserSpace,
aslo update nsSVGUtils::GetBBox accordingly.
MozReview-Commit-ID: BMjSonjoWd2
--HG--
extra : source : e32814fc5ab6fdb9e723b8109aa8f398b1c883f6
extra : histedit_source : 564968d47a3d95fde8e5b83c55148b63c1feb085
For nsSVGUtils::FrameSpaceInCSSPxToUserSpace:
If we give a nsSVGUseFrame to this function, it will return <use>'s x/y as
translation vector, which is not necessary. A point (a, b) in frame's
coordinate space should keep (a, b) in <use>'s coordinate space with no change.
Since we remove extra translation in nsSVGUtils::FrameSpaceInCSSPxToUserSpace,
aslo update nsSVGUtils::GetBBox accordingly.
MozReview-Commit-ID: BMjSonjoWd2
--HG--
extra : rebase_source : da629ba4464534a89718db1cd5b9705261ae4a4d
Sebastian Hengst
Jonathan Watt
cku
Iris Hsiao
Manish Goregaokar
Ryan VanderMeulen
Ryan Hunt
Wes Kocher
Robert Longson
Mats Palmgren
Carsten "Tomcat" Book
Timothy Nikkel
Boris Zbarsky
Ting-Yu Lin
Daniel Holbert
Jeff Walden
Cameron McCormack
Gijs Kruitbosch
Jonathan Kingston