New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 268213 link

Starred by 10 users

Issue metadata

Status: WontFix
Owner:
ooo
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 642368



Sign in to add a comment

performance.now() time not monotonic with respect to requestAnimationFrame callback time

Project Member Reported by shans@chromium.org, Aug 5 2013

Issue description

Version: 28.0.1500.95
OS: Linux

Calling performance.now() then scheduling an animation frame with requestAnimationFrame() should result in the animation frame callback being presented with a time larger than the performance.now() result. This is not currently true under certain conditions:
 * at document load time
 * if performance.now() and requestAnimationFrame() are called from an event handler.

It seems to be mostly true if the functions are called from a setTimeout callback.

Please see attached file for a repro.
 
test.html
1.1 KB View Download
Reproed here as well: http://jsfiddle.net/pehrlich/35pTx/
OK in firefox, not so in chrome.

Comment 2 by a...@lagoa.com, Nov 6 2014

I have confirmed this in my application. Firefox does not seem to suffer the same problem.

Comment 3 by a...@lagoa.com, Nov 6 2014

Here's a supporting fiddle http://jsfiddle.net/jh1bp534/ . Just run it and wait a few seconds. Give the browser some load by moving the dividers around.

Reproducible here on my MacBook, OS X 10.10, chrome 38.0.2125.111

Comment 4 by loyso@chromium.org, Apr 8 2015

Owner: loyso@chromium.org

Comment 5 by loyso@chromium.org, Apr 8 2015

Cc: tansell@chromium.org
Status: Available
Chrome	41.0.2272.118 (Official Build), Linux
1) attached test.html fails in onclick event handler callback
2) jsfiddle from #1 - flaky for fullscreen embedded result. Mostly 'true'.
3) jsfiddle from #3 - unable to reproduce.

Comment 6 by mit...@mithis.com, Apr 8 2015

Cc: -tansell@chromium.org mit...@mithis.com
loyso, mind if I take over this bug?

Comment 7 by loyso@chromium.org, Apr 9 2015

mithro, sure!

Comment 8 by loyso@chromium.org, Apr 15 2015

Owner: ----

Comment 9 by mit...@mithis.com, Apr 20 2015

Owner: mit...@mithis.com
I've taken a look at this and have a couple of theoretical code paths that could lead to this type of situation. 

The root of the problem is that we are processing input interleaved with animation. The following effect occurs;

 * We choose a time for animation
 * We run input handlers, which enable javascript RAF
 * We run animation handlers with the previously chosen animation time

One solution is to make sure that we always run the RAF in a frame *after* the one requested, this however introduces an extra frame of latency in input processing.

It is not clear to me yet if the behaviour (while possible unexpected) is actually *not* allowed by the current specification. There is also a good argument that there are cases where this behaviour is the right thing to do, specially when trying to be responsive to user input.

Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

-Anthony
Labels: -Cr-Blink

Comment 12 by mit...@mithis.com, Feb 24 2016

Cc: -mit...@mithis.com tansell@chromium.org
Components: Blink>Input
Labels: -OS-Linux -Hotlist-Recharge OS-All
Owner: briander...@chromium.org
The jsfiddle from alex@lagoa.com (http://jsfiddle.net/jh1bp534/) shows that this bug is actually still occurring in Chrome 48.

After looking into the specifications, it does seems like this behaviour **is** actually allowed (but might not be great thing to do). 

I believe this issue should be fixed by vsync aligned input. I'm making brianderson@ the owner who currently knows what is going on with that.
Is the Blink>Animation component appropriate for this bug?
Cc: ericwilligers@chromium.org
Components: -Blink>Animation
Cc: tdres...@chromium.org
This wouldn't be completely solved by vsync aligned input (or what we are calling RAF aligned input) because our currently proposal is to only run touchmove, mousemove, mousewheels be RAF aligned input. Not all input will be RAF aligned; as in this example clicks; mousedown, mouseup won't be RAF aligned.

It appears to be a design of requestAnimationFrame that if one is in the queue then you will get the next event. But it might be queued before the time you have queried performance.now()...


Cc: dtapu...@chromium.org
Blockedon: 642368
Components: -Blink>Input Blink>Scheduling
I think this is inherit in the design of requestAnimationFrame as tdresser@ pointed out. I'm not sure which component owns requestAnimationFrame but it isn't Input (and a number of other rAF things are in the scheduling bucket)
Cc: -tansell@chromium.org
Status: WontFix (was: Available)
It seems that this is the design feature of the requestAnimationFrame.

Closing this bug as a part of Blink>Scheduling bug review.

Sign in to add a comment