Bug 791675 - Scaled shapes fail to draw sometimes r=jwatt.

This commit is contained in:
Robert Longson 2012-12-20 13:49:54 +00:00
parent 7aa18132a1
commit 92ddd37dc0
2 changed files with 43 additions and 4 deletions

View File

@ -469,10 +469,28 @@ nsSVGImageFrame::ReflowSVG()
gfxContext tmpCtx(gfxPlatform::GetPlatform()->ScreenReferenceSurface());
gfxMatrix identity;
GeneratePath(&tmpCtx, identity);
// We'd like to just pass the identity matrix to GeneratePath, but if
// this frame's user space size is _very_ large/small then the extents we
// obtain below might have overflowed or otherwise be broken. This would
// cause us to end up with a broken mRect and visual overflow rect and break
// painting of this frame. This is particularly noticeable if the transforms
// between us and our nsSVGOuterSVGFrame scale this frame to a reasonable
// size. To avoid this we sadly have to do extra work to account for the
// transforms between us and our nsSVGOuterSVGFrame, even though the
// overwhelming number of SVGs will never have this problem.
// XXX Will Azure eventually save us from having to do this?
gfxSize scaleFactors = GetCanvasTM(FOR_OUTERSVG_TM).ScaleFactors(true);
bool applyScaling = fabs(scaleFactors.width) >= 1e-6 &&
fabs(scaleFactors.height) >= 1e-6;
gfxMatrix scaling;
if (applyScaling) {
scaling.Scale(scaleFactors.width, scaleFactors.height);
}
GeneratePath(&tmpCtx, scaling);
gfxRect extent = tmpCtx.GetUserPathExtent();
if (applyScaling) {
extent.Scale(1 / scaleFactors.width, 1 / scaleFactors.height);
}
if (!extent.IsEmpty()) {
mRect = nsLayoutUtils::RoundGfxRectToAppRect(extent,

View File

@ -309,7 +309,28 @@ nsSVGPathGeometryFrame::ReflowSVG()
if ((hitTestFlags & SVG_HIT_TEST_STROKE)) {
flags |= nsSVGUtils::eBBoxIncludeStrokeGeometry;
}
gfxRect extent = GetBBoxContribution(gfxMatrix(), flags);
// We'd like to just pass the identity matrix to GetBBoxContribution, but if
// this frame's user space size is _very_ large/small then the extents we
// obtain below might have overflowed or otherwise be broken. This would
// cause us to end up with a broken mRect and visual overflow rect and break
// painting of this frame. This is particularly noticeable if the transforms
// between us and our nsSVGOuterSVGFrame scale this frame to a reasonable
// size. To avoid this we sadly have to do extra work to account for the
// transforms between us and our nsSVGOuterSVGFrame, even though the
// overwhelming number of SVGs will never have this problem.
// XXX Will Azure eventually save us from having to do this?
gfxSize scaleFactors = GetCanvasTM(FOR_OUTERSVG_TM).ScaleFactors(true);
bool applyScaling = fabs(scaleFactors.width) >= 1e-6 &&
fabs(scaleFactors.height) >= 1e-6;
gfxMatrix scaling;
if (applyScaling) {
scaling.Scale(scaleFactors.width, scaleFactors.height);
}
gfxRect extent = GetBBoxContribution(scaling, flags);
if (applyScaling) {
extent.Scale(1 / scaleFactors.width, 1 / scaleFactors.height);
}
mRect = nsLayoutUtils::RoundGfxRectToAppRect(extent,
PresContext()->AppUnitsPerCSSPixel());