316165 - poor SVG performance on zoom with currentScale>8

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Andre Winter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

on files with more than a few kb (>100kb) firefox 1.5b2 makes the system hang when zooming in (by acting on currentScale) by steps 1, 2, 4, 8 etc. the rendering times takes more and more time, over 8, the browser freezes and lets the oparating system more or less no time & memory for reacting. shutting down the process is defficult because of very low reactivity of the system.

when passing from currentScale=8 to the next level, for ~30sec FF is not reacting. after that the system hangs too. when i get the taskmanager working the consumed memory by FF gets around 140000kb after those 30sec and drops down to 40000 after that. there is dumprep.exe doing something but never ending neither.

it is possible to shut down the processes (with a lot of patience), but the system needs a reboot after that. it seems as if this starts by FF trying to render offscreen (off-window) content that gets obviously big when zooming in. on files set up in a simlar way, e.g. <http://jwatt.org/svg/tests/zoom-and-pan-controlsViewBox.svg> but with less graphical content, the problem doesn't seem to exist.

i am having this problem on an ASUS laptop with an Intel graphcs card that causes some proiblems with OpenGL content (Google Earth), but otherwise this side doesn't seem to cause problems. on am older PC, the same problem occurs.



Reproducible: Always

Steps to Reproduce:
1. load SVG (>100kb) with zoom functionality
2. zoom in with currentScale over 8
3. firefox hangs, system hangs

Actual Results:  
system hangs.

Expected Results:  
further zoom in.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 ID:2005111123

WFM, takes a bit (too) long: 2 à 3 seconds.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Tried it again:
from 1 to 2 = 2 seconds;
from 2 to 4 = 2 à 3 seconds;
from 4 to 8 = 3 à 4 seconds.
I see high processor peaks as well.

Comment 3

[Jonathan Watt [:jwatt]]

Andre, b2 and b5 are way old, please update to rc2 and test again - there was a zooming perf fix landed fairly recently.

Comment 4

[Andre Winter]

(In reply to comment #3)
> Andre, b2 and b5 are way old, please update to rc2 and test again - there was a
> zooming perf fix landed fairly recently.

i have now RC2 (Gecko/20051107). it seems that the zoom-in goes further and the system doesn't hang. but FF freezes when passing from currentScale 4 to 8, the RAM usage evolves as described, and finaly FF crashes.

Comment 5

[Andre Winter]

btw, don't stop testing at currentScale 8, it is not there that a viewer should stop. as a comparision: batik squiggle stops on the step form 1048576 to 2097152 (not a joke). adobe's ASV also stops at a certain level, but there is no reason for.

andré

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to comment #5)
> adobe's ASV also stops at a certain level, but there is no reason for.

How do you know there's no reason? We limit you to a currentScale from 1/16 to 16.

Comment 7

[Andre Winter]

> How do you know there's no reason? We limit you to a currentScale from 1/16 to
> 16.

cannot imagine the spec limiting to 16...

anyway, hang/crash occurs between 4 and 8 and sooner if few other pan/zoom interaction take place before reachingt that level. zoom out doesn't cause these problems. didn't test with another viewBox though.

Comment 8

[Jonathan Watt [:jwatt]]

No, the spec. doesn't place a limit, but the spec. isn't the only factor in an implementation. The problem you're having is the reason for our limits, but apparently our they aren't strict enough to stop it occuring on your machine.

Comment 9

[Jonathan Watt [:jwatt]]

Andre, your testcase seems to have gone. Can you attach it to this bug so we don't loose it in future please?

Comment 10

[Andre Winter]

hi jonathan,

i don't have the file any more sorry, but this shows a similar behaviour, whereas it works better in FF 1.5.0.7. but full screen mode makes it still freezing and increasing memory usage: http://svg.carto.net/samples/99110.svg

Comment 11

[Wayne Mery (:wsmwk)]

Andrew, do you see this in seamonkey linux?  Is SVG an appropriate component? (could be a dupe, but no reduced testcase plus I don't know SVG and js)

confirming with http://svg.carto.net/samples/99110.svg each successive click of the "+" control takes longer. But results vary slightly...

w2k - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070427 Minefield/3.0a4pre
* when zoom=4, click + and after a good long wait the image blows the rest of the display (control elements) off the window. 

XP (faster PC) - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre 
* when zoom=4, click + and after a very short wait (2 sec) you get new screen
* when zoom=8, click - and after _long_ wait you get the updated screen
* when zoom=8, click + and after a very short wait (2 sec) you get new screen
* when zoom=16, click - and after a _long_ short wait (~30 sec) you get new screen at zoom=8

Comment 12

[Andre Winter]

i have only win boxes at hand. but i have been told that on other OSes the problem is similar.

btw. this problem is still present under FF3a4 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4) whereas since GranParadiso other examples work much better.

Comment 13

[Gavin Kistner]

No attachment and only the "but this one works fine" files seem to exist any more. Unable to test on OS X without a test case.

Comment 14

[Andre Winter]

Attachment: basic test case

replaces the original link posted in messages from 2005-2007, but is the same file.

Comment 15

[Andre Winter]

unfortunately a severe hard disk crash has killed our carto.net server while moving to annother location. this makes restoring hazardous. i attached the file now here (note that a 28kb background jpg is missing)

i can confirm that things work much better in FF3b3win, also with newer files. you may test/check with this here, set up in a similar way, with different content and iframe-based. note that this is work in progress and that the link is definitely temporary!

http://www.geotrace.net/temp/v92/

Comment 16

[Robert Longson [:longsonr]]

Seems OK now. It's possible the path speedup: http://muizelaar.blogspot.com/2010/01/graphics-performance-in-firefox-36.html has fixed things.