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
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.
