Re: SVG API for canvas

On Jun 11, 2014, at 8:35 AM, Philip Rogers <pdr@google.com> wrote:

> Alex,
> 
> The overhead of SMIL (aka FROWN) will be greater than the performance difference between javascript and C++. The math of calculating animation keyframes is negligible in either language. I wrote up a testcase of 15,000 simultaneous animations at http://pr.gg/smil.html
> 
> On Chrome 37.0.2042.0 (canary) the javascript+rAF testcase is 10% faster than SMIL. I profiled an instrumented build of Chrome and confirmed our SMIL code is hot on this testcase. Safari 7 feels similar to Chrome. On Firefox the javascript version certainly feels faster.

I think there are two sites:

Yes, SMIL requires a lot of synchronization with its sandwich model and makes it significant harder to optimize. However, I think we can both agree that the current Blink/WebKit code still has the potential for significant optimizations. At the moment we compute the value for each frame even in simple cases and still try to synchronize with other potential animations and check for event handlers. All that overhead is not part of your scripted version. From looking at examples on the web, it is unclear if the sandwich model is really what authors are looking for.

On the other hand, 10% performance lost to JS without a further optimized code path isn’t so bad. If you actually make use of the sandwich model, the code in Blink and WebKit should already look better. And SMIL can be a lot easier to type than setting up a scene by script.

Btw. the complexity doesn’t get lower with the Web Animations spec. Its concept of players, variable timelines and easing functions probably makes it more complex. We will see what impact that has on performance once there are first implementations. Of course SMIL would benefit of such an implementation as well and both would probably have the same performance characteristics.

Greetings,
Dirk


> 
> 
> 
> On Tue, Jun 10, 2014 at 6:07 AM, Alex Danilo <alex@abbra.com> wrote:
> >> On 6/9/14, 11:09 PM, Rik Cabanier wrote:
> >>> However, requestAnimationFrame should result in smoother animation than
> >>> SMIL.
> >>
> >> Why, exactly?
> >>
> >> -Boris
> >
> >In Blink (Chrome/Opera), svg animations (aka SMIL) are internally driven
> >by rAF too, so there should be no difference.
> 
> Boris is right, sorry.
> 
> JS driving the animation uses the JS engine to do the animation calculations
> instead of native code which can also take advantage of any browser internals
> it wants, like layers, etc.
> 
> When JS execution speed matches C/C++ this _might_ be moot but the best
> asm.js results still show 50% slow-down (addmittedly on non-critical render
> times from what I've seen), however claiming rAF is equivalent to SMIL for
> performance is a bit of a stretch. To claim rAF is smoother than SMIL needs
> some hard data to support, and I'd bet that's lacking, please contradict this
> with some numbers if I've missed something.
> 
> rAF can at best match but  not beat (or be smoother than) native SMIL if the stars are aligned nicely:-)
> 
> Alex
> 
> 
>

Received on Wednesday, 11 June 2014 07:15:56 UTC