Re: SVG API for canvas

Alex,

I don't think SMIL can be implemented off the main thread efficiently. SMIL
has more requirements than CSS animations (e.g., animating the class
attribute) and this pretty much requires that it be done on the main thread.

I'm aware of two independent implementations of SMIL and Javascript around
today: Gecko, and Blink (plus Webkit, which is similar to Blink here). In
neither of these is SMIL faster than Javascript. I have optimized Blink's
SMIL code and can say it will not be faster than rAF anytime soon.

Both theoretically and practically, SMIL is slower than javascript+rAF.


Chrome Canary on an ARM Android device runs the javascript approach 50%
faster than SMIL.


On Wed, Jun 11, 2014 at 5:28 AM, Alex Danilo <alex@abbra.com> wrote:

> 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
> >
> >
> >
> >
> >
> >
>
>