Draggable map slows down with big but simple svgs

[shy_seagull]

Hi!

I am currently working on a map-like showcase website for which I use the Draggable plugin. It worked out of the box without any issues. However now, that I am using 6 really big (in pixel size, not in complexion) svgs the dragging really slows down on my laptop. It’s hard to test on other devices right now, but it may be unusable for that reason now. As I have said before, the svgs only have fairly simple paths in them and should not be such an issue.

I have now found out, that when I use

gsap.set(map, { force3D: true });

it really helps with the smoothness of the dragging. The line in codepen is commented out, but you can test it by removing the comment. The problem is, the svgs have to be animated and as soon as the fill changes (In the codepen by simply clicking) it goes back to the laggy dragging, even when I use the force3D again afterwards.

 

Any idea how the performance could be improved? Thank you so much!

See the Pen ExKmoJK by lkssmnt (@lkssmnt) on CodePen

[GreenSock]

In almost every case, when you run into performance problems like that it has absolutely nothing to with GSAP/Draggable - it's all about graphics rendering in the browser. The more pixels that change on a given render/tick, the more work the browser must do. The way you've set things up is extremely demanding on the processor. SVGs are particularly problematic because they're vector-based, meaning the CPU must fabricate all the pixels on-the-fly (as opposed to raster images that have their pixels pre-packaged). It's not just about the complexity of the paths/artwork - it's about the total number of pixels that must be calculated. 

 

Also, filters and mix-blend-mode can be VERY expensive. Avoid those at all costs if you're running into performance problems. You're using mix-blend-mode, so I'd nix that. 

 

Setting force3D:true only helps when you're solely changing transforms or opacity because force3D encourages the browser to rasterize the element and push those pixels over to the GPU and then once they're on the GPU they're very cheap to move around with transforms. However, the moment you change the color or really anything else about that element (aside from transforms/opacity), the browser must dump the rasterized version and re-create it and push that new one over to the GPU. That's expensive. 

 

So again, none of this has anything to do with GSAP. You're pushing the browser too hard in terms of graphics rendering. 

 

Some strategies to reduce the CPU load:

• Use canvas or a library like PixiJS instead of SVG
• Hide elements that are off-screen so that the browser doesn't have to worry about rendering them. 
• Minimize the total number of pixels that must be repainted.
• Favor regular DOM elements (like <div>) instead of SVG wherever you can (like boxes) because they're much cheaper for the browser to render and can be GPU-accelerated more easily. 
• Avoid filters and mix-blend-mode. 

Good luck!

[shy_seagull]

Thank you so much for that incredibly detailed response and explanation! As the client indeed needs these exact forms and the multiply mix-blend-mode to overlap them, I should probably look into canvas!