Closed Bug 726928 Opened 8 years ago Closed 8 years ago
SVG elements disappear while zooming
In the latest nightly, zooming in or out of the attached SVG file results in elements disappearing. It's more noticeable while zooming out, as elements start disappearing on the first step. While zooming in it takes up to 4 increments for things to start vanishing. When zooming out, elements start vanishing from the right side, and when zooming in they start vanishing from the left side. It doesn't occur in a nightly build from about a week ago, fallout from bug 614732?
Might be just the same as bug 726911 which I filed earlier today.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed on the following str. http://hg.mozilla.org/mozilla-central/rev/c90c9f273cad Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120213 Firefox/13.0a1 ID:20120213031153 http://hg.mozilla.org/mozilla-central/rev/c90c9f273cad Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120213 Firefox/13.0a1 ID:20120213031153 Reproducible: Always Steps to Reproduce#1: 1. Start Firefox with new profile 2. Open http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-color-prof-01-f.html 3. Zoom out (Ctrl -), Zoom out (Ctrl -) ... Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/c8aee2ac4eba Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120210 Firefox/13.0a1 ID:20120210172614 Fails: http://hg.mozilla.org/mozilla-central/rev/d71dab82fff4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120211 Firefox/13.0a1 ID:20120211031145 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8aee2ac4eba&tochange=d71dab82fff4 Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/eb41457d5a4b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120209 Firefox/13.0a1 ID:20120209212515 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/073b91c24a1e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120210 Firefox/13.0a1 ID:20120210043613 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eb41457d5a4b&tochange=073b91c24a1e
OS: Mac OS X → All
Thanks, both of you, for the bug reports. I'll fix the issue here, Cam, since blocking and CCs are already set.
Assignee: nobody → jwatt
Hardware: x86 → All
Comment on attachment 597898 [details] [diff] [review] patch > nsPoint > nsSVGUtils::TransformOuterSVGPointToChildFrame(nsPoint aPoint, > const gfxMatrix& aFrameToCanvasTM, > nsPresContext* aPresContext) [...] >+ gfxMatrix canvasDevToFrameUserSpace = aFrameToCanvasTM; >+ canvasDevToFrameUserSpace.Invert(); >+ NS_ABORT_IF_FALSE(!canvasDevToFrameUserSpace.IsSingular(), >+ "Callers must check for singular matrix"); Nit: This seems a little late to be performing this assertion (_after_ the Invert call). Seems like it'd be better to check this first-thing, and check the passed-in "aFrameToCanvasTM" instead of your copy. const gfxMatrix canvasDevToFrameUserSpace = gfxMatrix(aFrameToCanvasTM).Invert(); r=me either way
Attachment #597898 - Flags: review?(dholbert) → review+
> const gfxMatrix canvasDevToFrameUserSpace = gfxMatrix(aFrameToCanvasTM).Invert(); (oops, ignore that line -- I was going to suggest making the canvasDevToFrameUserSpace declaration a one-liner, something like the above, but I decided it wasn't worth suggesting, and accidentally left the possible-line-of-code there :) )
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.