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
For an SVG container element(such as g/svg etc) used in mask, we apply
transform of it twice:
1. The first time is in nsSVGMaskFrame::GetMaskForMaskedFrame. We apply
transform by eAllTransforms(= eUserSpaceToParent + eChildToUserSpace)
2. The second time is in nsSVGDisplayContainerFrame::PaintSVG. We apply
transform by eChildToUserSpace
So, totally we apply 1 * eUserSpaceToParent + 2 * eChildToUserSpace. This
patch is trying to remove this one extra eChildToUserSpace.
MozReview-Commit-ID: 2pQCsrCIPNA
--HG--
extra : rebase_source : 27fe1648eb80d9c4d5111bbaec7ec38d80a0a8ac
More functions in nsCSSClipPathInstance will be refactored and moved into
ShapeUtils in subsequent patches.
MozReview-Commit-ID: LmJUevY8YGr
--HG--
extra : rebase_source : 8888fa26fab541d06a3fccad9e4376bb3a66c043
|center| should be of nsPoint type since all the arguments of
ComputeObjectAnchorPoint() uses nsPoint and nsSize. We should only convert
center to Point (which is an an UnknownUnits type) for APIs requiring Point
type.
MozReview-Commit-ID: EDrQGPUZp6m
--HG--
extra : rebase_source : a5494f969dcb08c139af076e95584502f46f0b9e
In the test case of bug 1324809:
1. A span is been broken into two continuation frames: FA and FB. FA is the first
connituation
2. Adding a filter effect to this span.
3. FA::FinishAndStoreOverflow is called. This function will call ComputeEffect:
if (nsSVGIntegrationUtils::UsingEffectsForFrame(aFrame)) {
aFrame->Properties().
Set(nsIFrame::PreEffectsBBoxProperty(), new nsRect(r)); // Now FA has
// PreEffectsBBoxProperty
// but FB does not
// have yet.
// ComputePostEffectsVisualOverflowRect will iterate all continuations from
// FA to FB. At this moment, FB does not carry PreEffectsBBoxProperty,
// assertion failure.
r = nsSVGIntegrationUtils::ComputePostEffectsVisualOverflowRect(aFrame, r);
}
4. FB::FinishAndStoreOverflow is called. But already too late.
MozReview-Commit-ID: 2c8OFzSLhfD
***
merge
MozReview-Commit-ID: C0lYQkKCYT6
--HG--
extra : rebase_source : d4777d5b60c9df78fd2ee1d734649b76579644c3