Improved SVG rendering speed in Google Chrome and Chromium

[mandulaj]

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 from 10 to 1. 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 the numOctaves value. From all tests I also concluded that Firefox has outperformed all the competitors in noise-rendering

Just for the sake of OCD this is the comparison between numOctaves: 1 and numOctaves: 10

The update time was on average 0.6 s for numOctaves:1 and 1.9 s for numOctaves:10

That 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)

[qrohlf]

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.

[mandulaj]

I see you increased the number to 3. That is Ok :+1:. 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 numOctaves: 10