New issue
Advanced search Search tips

Issue 827194 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 430155



Sign in to add a comment

Animation Worklet - Effect Proxy is reducing the precision of time.

Project Member Reported by majidvp@chromium.org, Mar 29 2018

Issue description

The time value is being truncated to 3 decimal points.

When a timeline that producestime values with many significant decimal figures. These values are being truncated when piped from currentTime to EffectProxy.localTime which can lead to visual jitter.


A ScrollTimeline with a large size and timeRange=1 will produce such time values.


```registerAnimator('twitter-header', class {
  constructor(options) {
  }

  animate(currentTime, effect) {
    effect.localTime = currentTime;
    console.log(`animate: ${currentTime}, localTime: ${effect.localTime}`, effect);

  }
});
```



 
We internally convert the time into a milliseconds value which I suspect is causes this: 
https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/modules/animationworklet/EffectProxy.h?type=cs&l=23


Cc: flackr@chromium.org surma@chromium.org
Status: Started (was: Assigned)
Here is the summary of my investigation:

In web animation, time values (e.g., duration, current time) etc, are specified in milliseconds. The
specification *recommends* implementations to be able to support precision up to microseconds.

Also internally, Chrome CC animation engine uses internal Chrome Time types, TimeTicks & TimeDelta
which have microseconds precision. 

The spec and chrome implementation, work fine for regular wall-clock time based animations where
microseconds precision is plenty. However ScrollTimeline timeRage concept allows the scroll size to
be mapped to any arbitrary range. This means that with a large enough scroller (e.g., >1000px) and a
small enough timeRage (e.g., <1ms), it is possible to have scroll offsets that don't map to distinct
time values. This can cause jitter where animation wants to position object relative to scroll
offset.


So ultimately I believe this is a specification issue.I suspect it will be hard to increase
recommended precision in Web Animation, so perhaps ScrollTimeline spec should have a warning about
this potential precision loss or reconsider the concept of timeRange.



[1]  https://drafts.csswg.org/web-animations/#precision-of-time-values
Status: WontFix (was: Started)
Filed a spec issue https://github.com/WICG/scroll-animations/issues/17
Project Member

Comment 4 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b060d29d94243bc0b41302758c6771775bc25f4b

commit b060d29d94243bc0b41302758c6771775bc25f4b
Author: Majid Valipour <majidvp@chromium.org>
Date: Wed Apr 11 12:03:49 2018

[animation-worklet] Add comment re potential precision loss in time conversion

Bug:  827194 
Change-Id: Ib21f0c55e2a196f75f3aa27ee0d0bc997a5b4bd1
Reviewed-on: https://chromium-review.googlesource.com/986750
Commit-Queue: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549860}
[modify] https://crrev.com/b060d29d94243bc0b41302758c6771775bc25f4b/third_party/blink/renderer/modules/animationworklet/effect_proxy.h

Sign in to add a comment