Re: SVG API for canvas

Hey Phil,

You missed the point I believe.

I wasn't talking about the "overhead of SMIL" which as you say has significance
cause the spec is less than ideal and we have to code around that.

I haven't even looked at your test case, but appreciate the effort to provide
hard data.

My point is that _any_ animation driven from rAF is locked into JS engine
on the main thread. 
SMIL and/or Web Animations/anything declarative can take
advantage of some smarts to offload things to either a compositor thread or
whatever parallel optimization the browser implementor has chosen to build.

So when you use rAF you are locked into main thread, period.

If you embrace declarative or more expressive animation primitves like
CSS animation and Web Animations (and SMIL if people would bother to write
it properly...) then the implementors can build a better experience given the
known constraints which don't exist from arbitrary JS execution. And therefore
we can be freed from things like the translateZ(0) hacks, etc.

That's the crux of my point, sorry if it wasn't clear.

And BTW, you should come to graphicalweb.org in August too:-)

Alex
P.S. I don't really care about the performance of Chrome Canary unless it's Chrome
running on ARM - just sayin'

--Original Message--:
>
>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.
>
>
>
>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 12:29:12 UTC