25404 2009-04-25 20:30:08 -0700 Bounds Calculation for Text stroke with opacity < 1 not correct 2010-07-01 09:11:39 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Mac OS X 10.5 RESOLVED FIXED P2 Normal --- 23881 1 jeffschiller webkit-unassigned krit oldest_to_newest 118871 0 jeffschiller 2009-04-25 20:30:08 -0700 The attached test case demonstrates an error in Webkit: When a <text> element has an opacity < 1.0, the calculation for the bounds of the stroke are incorrect (the left and right edges are erroneously clipped) 118872 1 29796 jeffschiller 2009-04-25 20:30:25 -0700 Created attachment 29796 Test Case showing the problem 118953 2 krit 2009-04-26 23:11:53 -0700 I see this problem on webkitgtk too. 119182 3 eric 2009-04-28 15:17:32 -0700 The problem here would be that FloatRect RenderSVGText::repaintRectInLocalCoordinates() const isn't including the stroke correctly, I suspect. It has some code which tries to include the stroke, but it must be wrong. It's also possible that this is a CG bug... because I don't think we specify the size of the transparency layer when we tell CG that we need to render transparent text... hum. 119183 4 eric 2009-04-28 15:20:47 -0700 krit and jamesr point out that the G in the second bottom left Gradient is cut off at the top in: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-pservers-grad-08-b.html Probably the same (or at least related) problem. 119191 5 krit 2009-04-28 15:45:01 -0700 (In reply to comment #4) > krit and jamesr point out that the G in the second bottom left Gradient is cut > off at the top in: > http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-pservers-grad-08-b.html > > Probably the same (or at least related) problem. It's not direclt related to this. The G-bug was a problem in SVGResourceGradient and it's neither a CG-bug. I see it on WebKitGtk. We must have a check, if opacity<1 use objectBoundingBox or something like that. 119193 6 eric 2009-04-28 15:58:02 -0700 There are a couple places where we're still using objectBoundingBox() where we mean repaintRectInLocalCoordinates() However changing those didn't fix the entire problem for full-pservers... I think the full-pservers... bug is a separate issue. This bug is likely cause by this code: void SVGRootInlineBox::paint(RenderObject::PaintInfo& paintInfo, int tx, int ty) { if (paintInfo.context->paintingDisabled() || paintInfo.phase != PaintPhaseForeground) return; RenderObject::PaintInfo savedInfo(paintInfo); paintInfo.context->save(); SVGResourceFilter* filter = 0; FloatRect boundingBox(tx + x(), ty + y(), width(), height()); // Initialize text rendering prepareToRenderSVGContent(renderer(), paintInfo, boundingBox, filter); Which is using a bad boundingBox calculation there. prepareToRenderSVGContent needs to be changed to take a separate objectBoundingBox() and repaintRectInLocalCoordinates() and use the repaint rect for the opacity clip (which we do set up manually) and the objectBoundingBox for filter setup (which we're not actually doing in ToT since filters are turned off). maybe x(), y(), width(), height() is right, but I doubt it includes stroke width. SVGRootInlineBox probably needs its own repaintRectInLocalCoordinates() method. 119195 7 eric 2009-04-28 16:00:42 -0700 I've split the 'G' painting bug off into its own bug: https://bugs.webkit.org/show_bug.cgi?id=25460 176055 8 krit 2009-12-30 14:44:54 -0800 (In reply to comment #6) > There are a couple places where we're still using objectBoundingBox() where we > mean repaintRectInLocalCoordinates() However changing those didn't fix the > entire problem for full-pservers... > > I think the full-pservers... bug is a separate issue. This bug is likely cause > by this code: > > void SVGRootInlineBox::paint(RenderObject::PaintInfo& paintInfo, int tx, int > ty) > { > if (paintInfo.context->paintingDisabled() || paintInfo.phase != > PaintPhaseForeground) > return; > > RenderObject::PaintInfo savedInfo(paintInfo); > paintInfo.context->save(); > > SVGResourceFilter* filter = 0; > FloatRect boundingBox(tx + x(), ty + y(), width(), height()); > > // Initialize text rendering > prepareToRenderSVGContent(renderer(), paintInfo, boundingBox, filter); > > Which is using a bad boundingBox calculation there. prepareToRenderSVGContent > needs to be changed to take a separate objectBoundingBox() and > repaintRectInLocalCoordinates() and use the repaint rect for the opacity clip > (which we do set up manually) and the objectBoundingBox for filter setup (which > we're not actually doing in ToT since filters are turned off). > > maybe x(), y(), width(), height() is right, but I doubt it includes stroke > width. SVGRootInlineBox probably needs its own repaintRectInLocalCoordinates() > method. I thing you're right. We give the objectBoundingBox to prepareToRenderSVGContent instead of the repaint Rect. This is wrong. It's not neccessary to give the obb to prepareToRenderSVGContent. It already has the object and can ask for the obb itself. 245373 9 krit 2010-07-01 09:11:39 -0700 This is fixed with trunk. Closing the bug. 29796 2009-04-25 20:30:25 -0700 2009-04-25 20:30:25 -0700 Test Case showing the problem text-stroke-opacity.svg image/svg+xml 380 jeffschiller PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxz dmcgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDov L3d3dy53My5vcmcvMTk5OS94bGluayIgdmVyc2lvbj0iMS4xIiB3aWR0aD0iODUwIiBoZWlnaHQ9 IjIwMCIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI+CiAgPHRleHQgeD0iMzAiIHk9IjYwIiBzdHJva2Ut d2lkdGg9IjgiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIg b3BhY2l0eT0iMC45OSIgc3Ryb2tlPSJibGFjayIgZm9udC1zaXplPSI1MS41cHgiIGZvbnQtd2Vp Z2h0PSJib2xkIj5TVkcgT3BlbiAyMDA5PC90ZXh0Pgo8L3N2Zz4=