Closed Bug 948848 Opened 6 years ago Closed 6 years ago
Rendering of svg content embedded inline in outer svg is erroneously clipped depending on zoom scale
4.34 KB, image/svg+xml
36.26 KB, image/jpeg
48.26 KB, image/jpeg
2.03 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Steps to reproduce: In attached SVG file wrong_clip.svg, there is polygon embedded inline in one svg content, and grips created in other svg content. Both svg's are embedded in common "drawing" svg that is embedded via "viewbox" svg in root svg. This is excerpt from arrangement created for viewing and editing svg drawings. To reproduce, open attached wrong_clip.svg in FF. Actual results: Parts of polygon are erroneously clipped, and some grips are not displayed. This behavior changes while changing View - Zoom level (Ctrl++ or Ctrl+-). Polygon becomes clipped in other way or revealed in whole, some other grips are revealed partially or in full. Expected results: Polygon and all grips should be displayed in whole, regardless of view scale. The same example opened in Chrome renders properly.
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/fc1684f4d3a9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121114044850 Bad: http://hg.mozilla.org/mozilla-central/rev/87928cd21b40 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121114063649 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fc1684f4d3a9&tochange=87928cd21b40 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/2b66b88a0b0f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121113221949 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/24c0c55af0ed Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121113222650 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2b66b88a0b0f&tochange=24c0c55af0ed In local build, Last Good: 2e813df0aca1 First Bad: 1cfa8c4279e5 Regressed by: 1cfa8c4279e5 Matt Woodrow — Bug 810186 - Don't unnecessarily nest inactive layers. r=roc
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 29 Branch → 19 Branch
setting layers.force-active = true helps
Component: SVG → Layout
Assignee: nobody → matt.woodrow
After reducing the test case, the relevant piece of the display list is: nsDisplayTransform 0x168945880(SVGG(g)(1)) bounds(19847,2359,29395,31726) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,6000,74880,30360) nsDisplayTransform 0x168945da0(SVGPathGeometry(polygon)(1)) bounds(-324,45,829,874) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(-88,-1,809,686) nsDisplaySVGPathGeometry 0x168945da0(SVGPathGeometry(polygon)(1)) bounds(0,0,828,873) visible(0,0,0,0) componentAlpha(0,0,0,0) clip() When building the layer for the inner nsDisplayTransform, we treat it as active, since we're already inside an inactive layer tree. The Layers API only supports pixel aligned (nsIntRect) clips, so we snap the clip rect to the nearest pixels. For retained layers this doesn't matter, since we never change the clip by more than half a pixel. But since this is a temporary layer manager, the clip will be transformed by the parent layer, and our snapping ends up having a large difference. We could change the layers API to take gfxRect (float) clips instead, or go back to nesting inactive layer managers if the inner one has a non-pixel-aligned clip.
This isn't an issue with active layers since we fold the transform scale factors down into the leaf layers, and avoid accumulating the error that way.
Turns out that it does matter!
Attachment #8347854 - Flags: review?(roc)
Attachment #8347854 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Verified as fixed with latest Aurora on Win 7 x64.
You need to log in before you can comment on or make changes to this bug.