Improved SVG rendering speed in Google Chrome and Chromium #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Why bother typing `gulp` each time I want to recompile...
|
Thanks for doing the digging on this. I'm curious - how are you timing the time for the browser to render the SVG? Can you attach a listener of some kind to the SVG that gets fired when the render is complete? I'm getting merge conflicts when I try to rebase this onto the current version. Since the 4 commits in this PR effectively only change one line of code, I'm going to port this over manually. |
qrohlf
added a commit
that referenced
this pull request
Oct 8, 2014
This commit decreases the numOctaves used in the feTurbulence fractalNoise SVG filter from 10 to 3. @zpiman investigated this in PR #23 and found it to have a significant impact on SVG render time. While I found that reducing it all the way down to 1 caused a visual impact on the generated noise, 3 seems to be a good compromise that improves performance significantly while staying visually indistinguishable from 10.
|
I see you increased the number to 3. That is Ok 👍. Also with the timing as far as I know you can't attach any callback to the SVG rendering. So I first used the old style: load the page and start the stopwatch method. But now I am using the dev tools Timeline -> look for the long paint process. numOctaves: 3 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After doing a few experiments I concluded that Google Chrome 37.0.2062 (64-bit) has the worst SVG noise rendering implementation. Chromium v40.0.2172 (64-bit) is still slow but it is significantly faster! For the purpose of speeding up the rendering I suggest reducing the
numOctavesvalue from10to1. The rendering speed improvement is far more obvious then the visual difference. Also comparing Google Chrome and Firefox yields a much greater visual difference then tweaking thenumOctavesvalue. From all tests I also concluded that Firefox has outperformed all the competitors in noise-renderingJust for the sake of OCD this is the comparison between
numOctaves: 1andnumOctaves: 10The update time was on average 0.6 s for
numOctaves:1and 1.9 s fornumOctaves:10That is more then twice as fast render time.
(All Tests were performed using Windows 8.1 and Debian 7.6 running on a Intel i5-3330 3.0GHz quad-core and NVIDIA GeForce GT 630)