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

Categories

(Core :: Layout, defect)

19 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla29
Tracking Status
firefox26 --- affected
firefox27 --- affected
firefox28 --- affected
firefox29 --- verified
firefox-esr17 --- unaffected
firefox-esr24 --- wontfix

People

(Reporter: krzysztof.finowicki, Assigned: mattwoodrow)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(4 files)

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
Blocks: 810186
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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)
https://hg.mozilla.org/mozilla-central/rev/c2362348473c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Blocks: 836325
Keywords: verifyme
Verified as fixed with latest Aurora on Win 7 x64.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Depends on: 1107104
You need to log in before you can comment on or make changes to this bug.