Re: Deferring SVG DOM to a separate module

On 11/06/2015 3:46 am, Brian Birtles wrote:
> 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?
This was in reference to a comment I made, although I didn't mention
threading.
The issue I raised was that in WebKit, the SVG implementation is so
overly complex and horrible, that it blocks implementing a lot of things.
So it's a chicken and egg thing, we want Web Animations so that we have
a replacement, but the current architecture means that implementing Web
Animations is a lot more difficult.
If we aliased animVal to baseVal it would simplify things and greatly
speed up the refactoring of the SVG code to support Web Animations.
We would want a way to obtain the animated value somehow though.
>
>> 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
>

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 11 June 2015 06:31:33 UTC