Issue metadata
Sign in to add a comment
|
DocumentTimeline.currentTime should match rAF now |
||||||||||||||||||||||||
Issue description
According to specification [1]
"The time passed to a requestAnimationFrame callback will be equal to document.timeline.currentTime"
For example:
window.requestAnimationFrame(function(now) {
// Displays 0
console.log(now - document.timeline.currentTime);
});
Testing this in Linux I am getting a changing value that is not Zero.
The difference value slowely moves from -16ms to 0 and back. Pretty sure this is because AnimationClock approximate frame and the clocks are slightly different. [2]
[1] https://drafts.csswg.org/web-animations/#model-liveness
[2] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/animation/AnimationClock.cpp?sq=package:chromium&l=41
,
Jan 10 2018
Yes. That is pretty much my repo.
,
Jan 14 2018
> Pretty sure this is because AnimationClock approximate frame and the clocks are slightly different. [2] AnimationClock should source its time the same way as RAF (during raf callback tasks). The approximation is only used for tasks outside frame callbacks. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/PageAnimator.cpp?sq=package:chromium&l=34
,
Jan 14 2018
So if the delta is non-zero during requestAnimationFrame, then we must have incorrectly called AnimationClock::NotifyTaskStart (i.e. putting us in the outside frame callbacks approximation mode).
,
Jan 15 2018
,
Jan 16 2018
,
Mar 2 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by smcgruer@chromium.org
, Jan 10 2018222 bytes
222 bytes View Download