D3.js: spelling optimization

Question

I made a map using orthogonal projection and I try to improve performance because the rotation is not smooth (about 6-7FPS).

This is a world map built with a topojson file (world-100m). I need to interact with the country and colorize them so that there are as many svg: path as there are countries .

After loading, I have an automatic rotation function launched using d3.timer:

autoRotate = () => @start_time = Date.now() # Store the current time (used by automatic rotation) d3.timer () => dt = Date.now() - @start_time if @stopRotation or dt > @config.autoRotationDuration true else @currentRotation[0] = @currentRotation[0] - @config.autoRotationSpeed @projection.rotate @currentRotation redrawPathsOnRotationOrScale(@currentRotation, @projection.scale()) false redrawPathsOnRotationOrScale = (rotation, scale, duration = 1) => @currentRotation = rotation @projection .rotate(@currentRotation) .scale(scale) @groupPaths.selectAll("path") .attr("d", path) 

To understand why this was so slow, I recorded a profile in Chrome and here is the result:

Animation Frame Fired seems to be the slow part, but I don't know what it is. And when I open it, there is 2 GC Event (garbage collector?), But nothing around ... Do you have an idea what happens during these 90 ms?

Any tips for improving performance are more than welcome :-)

Thanks in advance!

By the way, it looks like this:

Answer 1

Try reducing the complexity of SVG paths by setting the -simplify-ratio, -s, or --quantization topojson flags. Browsers still have pretty poor SVG rendering performance, and with maps it really helps to reduce the number and accuracy of points.

Answer 2

D3.js uses Request Animated Frames to execute timers.

From the D3 documentation :

If your browser supports it, the timer queue will use requestAnimationFrame for fluid and efficient animation.

As I know, this is the best approach to animation in modern browsers, and I don’t think you can directly optimize this part. Otherwise, it seems like you are calling the stack using selection_each , which could probably be cached into a variable.