Closed
Bug 780762
Opened 13 years ago
Closed 8 years ago
Janky scrolling when a particular SVG is on-screen
Categories
(Core :: SVG, defect)
Core
SVG
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?
Reporter | ||
Updated•13 years ago
|
Whiteboard: [dupeme]
Comment 1•13 years ago
|
||
+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.
![]() |
||
Comment 2•13 years ago
|
||
![]() |
||
Comment 3•13 years ago
|
||
![]() |
||
Comment 4•13 years ago
|
||
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.
![]() |
||
Updated•13 years ago
|
OS: Linux → All
Hardware: x86_64 → All
![]() |
||
Updated•12 years ago
|
![]() |
||
Updated•11 years ago
|
Whiteboard: [dupeme] → [in-the-wild] [dupeme]
![]() |
||
Comment 5•8 years ago
|
||
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>
![]() |
||
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•