Re: JavaScript-Driven Accelerated Animations

On Wed, Oct 2, 2013 at 6:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>
> On Wed, Oct 2, 2013 at 3:38 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> > On Wed, Oct 2, 2013 at 6:29 PM, Ian Vollick <vollick@chromium.org> wrote:
> >> No, the compositor should never block. All interactions between the proxy
> >> on the worker and the compositor thread will need to be asynchronous.
> >
> > OK, so the quality of animations produced by this approach will be better
> > than animations produced by main-thread JS but worse than animations
> > performed by the compositor directly.
>
> Precisely correct.

That said, there are things we might consider that could get the
performance of the worker driven animations close to that of
compositor driven animations. Say the getters (perhaps different
getters) were to return 'deferred' values that represent the current
scroll offset/opacity/transform. We might interact with these deferred
values on the worker (e.g., we could scale, add, multiply them, etc),
but not query them directly. If an expression involving a deferred
value were sent to the compositor, the compositor could replace the
deferred values with the true current values at the last minute.

Received on Wednesday, 2 October 2013 22:55:04 UTC