SMIL vs JavaScript (was: SVG API for canvas)

On Wed, Jun 11, 2014 at 12:38 PM, Philip Rogers <pdr@google.com> wrote:

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

I agree with Philip.
The performance and convenience of JavaScript is not something that can be
ignored.
SMIL has been in the most popular browsers for a long time now and adoption
is still extremely low.
Meanwhile, CSS animations and transitions are very popular. More complex
"cartoon" animations are done with video or using script libraries.

We should rethink what is needed for interactive animations on the web.
In my mind there are 3 types of 2D animations:
1. simple non-synchronized moving of an element such as CSS animations.
Triggers are asynchronous. Timing is done in seconds.
2. Hanna-Barbera style animations (see
http://en.wikipedia.org/wiki/Limited_animation for the model). Triggers are
synchronous. Timing is in frames
3. fluid vector animation (such as After Effects' puppet tool [1] or
toonboom's animate pro [2]). Mostly exported as movies.

use case for 1: visual interest, hover effects
use case for 2: games, simple cartoons, rich interactive animations
use case for 3: "modern" life-like cartoons

requirements for 1: deeply embedded in the page markup, highly fluid, part
of the page layout
requirements for 2: can run in sandbox. Little interaction with main page
and this can be asynchronous and only in script. Has its own DOM.
requirements for 3: none. access to a video player.

SMIL seems to target a more complex model of type 1 animations. Web
Animations is also targeting type 1.

Today people are using JavaScript to do type 2 style animations (such as
Adobe's Edge Animate [3] or CreateJS [4]).
I would be more interested in how we can solve the pain points with this
approach.
For instance:
- can we give them their own worker? (faster + synchronous events won't
block main thread)
- can we give them a private RaF that only fires when the movie is visible
and is called independent from the main page?
- would they be satisfied with a lighter DOM? (ie only SVG/Canvas/WebGL)
- would they be interested in an animation model or does JS work fine for
them?


1: https://www.youtube.com/watch?v=9FKaPBAUBNY
2: https://www.toonboom.com/products/animate-pro
3: http://html.adobe.com/edge/animate/showcase.html
http://html.adobe.com/edge/animate/showcase/modern-web/
4: http://b10b.com/iondrift/epsilon/html5-createjs/


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