Closed Bug 780762 Opened 12 years ago Closed 7 years ago

Janky scrolling when a particular SVG is on-screen

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: justin.lebar+bug, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: perf, Whiteboard: [in-the-wild] [dupeme])

Attachments

(2 files)

http://webhome.cs.uvic.ca/~ruskey/Publications/Venn11/Venn11.html

Scrolling is very janky on my machine when the images directly the text "Below is the diagram drawn on the plane, with two different styles of filling." are on screen.

Surely we should cache the rasterized SVG, so scrolling it should not be any worse than scrolling a PNG?
Whiteboard: [dupeme]
+cc: jwatt

I don't know what's on the stack as we scroll down to this graphic, but I'd like to see how this looks now that bug 614732 has landed.
Keywords: perf
Attached image SVG for test
We do now seem to be caching the rendering of the SVG that's been painted. So if the SVG is scrolled entirely into view, then at least some of the time that you scroll it (keeping it entirely in view) it scrolls smoothly. Unfortunately there are at least three issues that thwart us and make scrolling of the attached test suck.

Although it doesn't visually look like it, the SVG is actually using gradients for the > 2000 paths being drawn. This is a bit silly, since the x1, y1, x2 and y2 attributes are all set to the same value, meaning that the paths are only filled with a single color even though we go through the expensive gradient painting paths. That said, even if the SVG is changed to make proper use of gradients so that the paths are visually filled with gradients, we are much slower than Chrome and Opera. So the first problem seems to be that our gradient painting code sucks and is way too slow.

A second issue is that when an <img> tag is used to reference the SVG (as in the testcase), we repaint the _entire_ <img> even when only a small sliver of it is moved further on screen. (If the <img> is replaced by an <iframe>, we only repaint the small sliver that moved on screen, which is much less of a hit.)

A third issue is that we seem to be hitting bug 777194, so every so often while scrolling the _entire_ content area of the browser is repainted, which is what causes scrolling to freeze every so often even when moving the SVG from one entirely-on-screen position to another entirely-on-screen position.
OS: Linux → All
Hardware: x86_64 → All
Depends on: 777194
Depends on: 793484
Depends on: 876175, 876157
Depends on: 869505
Whiteboard: [dupeme] → [in-the-wild] [dupeme]
This seems to be WORKSFORME now. Paint flashing is showing some invalidation at the corners of the viewport when scrolling around the center of the image, but that reproduces on this data URI:

data:text/html,<div style="display:block; height:1000px"></div><img style="width:10000px; height:200px"><div style="display:block; height:1000px"></div>
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: