Closed
Bug 561357
Opened 14 years ago
Closed 7 years ago
Large/complex SVGs lock up browser interface when loading, redrawing window.
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: M8R-mt57m6, Unassigned)
References
()
Details
(Keywords: hang, perf, Whiteboard: [in-the-wild] [external-report][perf:painting])
Attachments
(1 file)
1.90 MB,
image/svg+xml
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre (.NET CLR 3.5.30729) When visiting http://michaelt.uwcs.co.uk/unviewboxed.svg the browser consumes 100% CPU and the user interface becomes unresponsive until the image is fully drawn on screen. This takes several minutes on my computer. This also happens when I change tabs away from the svg then back to it; when I change windows; and so on. Reproducible: Always Steps to Reproduce: 1. Use a computer with, say, a Pentium 4 or Atom processor. 2. Load system monitor to view CPU usage. 3. Visit http://michaelt.uwcs.co.uk/viewboxed.svg 4. Observe the locked-up state of the browser's user interface and 100% CPU usage. 5. Try changing between tabs (and between windows) so the svg gets redrawn. Actual Results: Takes several minutes to draw the image, change tabs, redraw window. Expected Results: One of: (a) the rendering to abort after about 60 seconds (b) an error message (similar to the unresponsive script error message) after the same time (c) the rendering to take place in a separate thread so the user interface doesn't lock up. Also, optionally, (d) caching the rendered image as a bitmap, so that images which are slow to initially render do not have to be re-rendered every time the window is redrawn (such as when changing tabs or changing windows). Has obvious denial-of-service implications.
Comment 2•14 years ago
|
||
> (a) the rendering to abort after about 60 seconds That may be difficult if the time is actually spent in OS drawing code. > (c) the rendering to take place in a separate thread so the user interface > doesn't lock up. Being worked on: https://wiki.mozilla.org/Electrolysis > (d) caching the rendered image as a bitmap Being worked on: https://wiki.mozilla.org/Gecko:Layers
Comment 3•14 years ago
|
||
Freezes Opera too FWIW.
Comment 4•14 years ago
|
||
The test file is consists of around 19500 rects. This is an example. <rect style="fill:none;stroke:#000000;stroke-width:2px" width="0.000008" height="0.000011" x="-1.558505" y="52.383966" />
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [in-the-wild] [external-report]
Updated•10 years ago
|
Whiteboard: [in-the-wild] [external-report] → [in-the-wild] [external-report][perf:painting]
Comment 5•7 years ago
|
||
A profile of me zooming in multiple times on the SVG shows 90%+ of the time spent under DrawTargetSkia::StrokeRect. There's not much we can do to improve that. https://perfht.ml/2nR7cPb Also we don't seem to perform so differently to Chrome.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•