Re: Deferring SVG DOM to a separate module

On 2015/06/11 0:55, Amelia Bellamy-Royds wrote:
> For now, one specific change we discussed was neutering "animVal" so
> that it is always an exact synonym for "baseVal".  From the
> implementation side, this makes it much easier to move forward with web
> animation optimizations on a separate thread, if they don't have to keep
> updating data accessible from the main thread.

I don't understand this. How is it different to CSS where animations not 
happening on the main thread still need to update the computed style 
returned on the main thread?

> I am assuming that web animations will offer an alternative, thread-safe
> way of accessing this information (e.g., when an animation is
> paused/interrupted because of user action, you need to figure out where
> everything currently is before setting up a new animation), but I'm not
> sure how this would work (maybe by passing a specific time value to the
> animation, instead of asking for "current value"?).

Exposing this is really an issue for SVG. For CSS we can (sort-of) get 
the animated value using getComputedStyle (which may not actually be the 
animated value since it could be overwritten by !important rules etc. 
but it answers the question, "what color is this thing now?").

For any attributes SVG defines as animatable that are not presentation 
attributes, SVG needs to define how to get the animated value, if at all.

We've talked about adding API to Web Animations that would let you ask, 
"What's the contribution of this particular animation to property x?", 
possibly providing the time as an argument, but that's a long way off 
and would need a wrapper to make it useful in this case.

With regards to multiple threads/processes, in Gecko (and I'm pretty 
sure other engines are the same here) we run the animation twice in 
effect. On the compositor thread/process we try to run it at 60fps and 
on the main thread we throttle it so that we only update style when we 
need to (e.g. someone calls getComputedStyle).

Obviously that means there will be some discrepancy between the values 
you get back from getComputedStyle and whatever the compositor is 
currently generating (particularly if either thread/process is bogged 
down) but I don't see an easy way around that. For applications where 
that discrepancy is unacceptable we might need to provide a way for 
authors to force their animations to run on the same thread as their JS.

Best regards,

Brian

Received on Thursday, 11 June 2015 01:47:12 UTC