Hardware acceleration and SVG

[Pilatus]

Hello guys,

 

In our project we develop an aircraft simulator with the cockpit visuals running in the browser (there is no landscape visualization). We started in 2010 with this project and our only choice by then was pretty much Adobe Flash. Flash hasn't been an easy path, but with optimization and elegant code we achieved excellent results, it just allowed us to do everything we wanted and quickly. We are planning to move the whole front-end to SVG. We've been relentless till now because of the browser lack of support and the immense amount of work to do the port. So it wasn't really worth. Now we decided to push a bit the limits with SVG and test the feasibility at the present time. Another reason for the change is that we feel Flash is being abandoned on the long term (5-10 years from now).

Passing from flash to pure SVG graphic would allow us to support multiple browser/platforms.

We will be having "many" objects on the screen, let's say up to 500 with a good 25% of them animated in the worst case, everything runs in full screen. Animations will be pretty much scaling, translations, opacity fade ins/outs, rotations, masking.

 

My question is , in the current state of the modern browsers, which operations are more likely to be hardware accelerated when animating SVG? Recently I've read SVG is not yet accelerated at all, is it true?

Is there any trick which I need to follow to speed up the tweens?

 

 

 

[Carl]

Hi,

 

To our knowledge, SVG elements are not hardware accelerated. I'm not really sure what can be done to speed them up.

As you probably know from the Flash days, vector graphics were great for their small file size and scalability but they ate up a lot of resources when it came to animating them – which led to cacheAsBitmap. Rasterizing the vectors that didn't need to scale gave folks a huge performance boost.

 

I think the same holds true for the browsers: re-calculating all the vector data at 60fps can be quite expensive and I'm not sure what optimizations need to happen in the browser to make it better. For what its worth, I've seen great performance of SVG animation with GSAP on desktop and mobile, but frankly nothing that has really pushed the limits (100s of concurrent tweens). 

 

Keep an eye on our SVG tips page newsletter. If we find out any great SVG tips we will be sure to announce them there.

[alarik]

Hi all,

 

i came to this forum by chance. I'm working on a project that foresees zooming quickly and smoothing inside SVGs.

I've a lot of experience in this topic since I tried any possible way to achieve the best performances but when a portion of the image is zoomed very very deeply, the movement is not anymore smooth, probably because the browser renders also the not visible part of the image (a very zoomed image can reach resolutions like 100.000x100.000 pixels when built from vector's data). This happens also for fonts.

So I confirm SVGs are not hardware accelerated. 

If anybody has any news on this topic I'll be glad to read it.

thanks

 

Alarik

[OSUblake]

Hi @alarik,

 

Outside of rasterized transforms, I seriously doubt you're going to be seeing hardware accelerated SVGs anytime soon. Its more of a GPU issue than a browser one. You really can't render a path on a GPU. Not to say it can't be done, it's just not trivial.

 

GPUs work with a fixed number of triangles. Paths are not defined by triangles, nor do all the points of a path lie on the path itself e.g. Beziers. It's not too hard to approximate a path as bunch of triangles, see this CSS-Tricks article, but that also means your path is no longer resolution independent. Zoom in enough, and you'll eventually see those triangles.

 

There are ways around that, like using signed distance fields. Check out this example for rendering text from bitmaps. It always messes with my head when I see it.

http://wdobbie.com/pdf/

 

Another problem with GPUs is that it's really hard to draw a line. I know that sounds really simple, but it's not. When you increase the width of a line, the corners don't join up that well.

 

 

A common work-around for this is... yep, more triangles, which must fist be calculated on the CPU.

 

 

 

So for now I would say that if you need really fast zooming, your best bet is to use WebGL, or a library that supports it like Pixi.js, Three.js, or Babylon. 

.