Closed Bug 561357 Opened 15 years ago Closed 8 years ago

Large/complex SVGs lock up browser interface when loading, redrawing window.

Categories

(Core :: SVG, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: M8R-mt57m6, Unassigned)

References

()

Details

(Keywords: hang, perf, Whiteboard: [in-the-wild] [external-report][perf:painting])

Attachments

(1 file)

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.
> (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
Freezes Opera too FWIW.
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" />
Depends on: 876234
Keywords: hang, perf
Whiteboard: [in-the-wild] [external-report]
Whiteboard: [in-the-wild] [external-report] → [in-the-wild] [external-report][perf:painting]
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: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: