Note that using 

window.requestAnimationFrame=function(cb){
  window.setTimeout(cb,16.6);
}

does fix it on sketchfab, so really related to RequestAnimationFrame.

The RequestAnimationFrame might not be the culprit as it didn't "fix it" (I thought so because our stats displayed 60fps) but it was still around displayed around ~40 fps max in practice. So not sure if rAf is the cause or the consequence here...

On several windows 10 pc configurations, the above url run at 60 fps on chrome 49, firefox, and edges. (I think it was working fine on 51 although I don't have any 51 build).

However :
- it run around ~40 fps on chrome 50.0.2661.75 m
- the weird thing is run ~40 fps on canary too 52.0.2713.0 BUT it runs 60 fps on toji last custom vr build (52.0.2711.0) https://webvr.info/get-chrome/

We are trying to pin-point the issue but it's kind of confusing at it only happens in some version of chrome and on sketchfab.
It's "possible" the issue is coming from some web stuffs as the webgl engine we are based on does not have this issue in a non-sketchfab context (http://osgjs.org/examples/picking/?stats=1 is running at 60 fps everywhere)

var func = function () {
    window.requestAnimationFrame( function () {
        console.timeEnd( 'yo' )

        console.time( 'yo' )
        func();
    } )
}
func();

^ the above script on an empty page on the problematic pc/chrome combo will display a few ~33.3ms, but on the non-problematic chrome, it only display 16.6ms

I'm unable to reproduce the issue with your function in comment #5. One important difference between setTimeout and requestAnimationFrame (which may have led to the conclusion in comment #1) is that the latter will wait until the start of the next frame, this means that if your work in any frame takes slightly longer than a frame it will miss the next frame and delay until the following frame (i.e. 33.3ms). Using setTimeout however is free to run at any point during a frame.

Is your system busy? Do you experience the same problem when running in an incognito window (i.e. with no extensions running)? You can try recording the timeline in developer tools or a trace using chrome://tracing to find out exactly what is happening that may be causing your rAF function to miss the frame deadline.

indonesia
21 Apr 2016 04.31, "flackr@chromium.org via Monorail" <monorail@chromium.org>
menulis:

Yep comment #1, we can forget about it :).

Yes I tried incognito (the canary build has the issue too and was new install) and it's the same : ~40 fps.

Encode the 2 timeline (one OK and one other not OK).
I can't really find any explanation by looking at the timeline... it's mostly idling.

Deleted: timeline40.jpg 106 KB

	timeline40.jpg 106 KB View Download

Deleted: timeline60.jpg 150 KB

	timeline60.jpg 150 KB View Download

... hmm when I go fullscreen it's always 60 fps

I was able to repro on our Win 10 testing machine using the jsfiddle example. With Chrome 50, I saw the occasional ~33ms in normal view but not when fullscreen. With Chrome 52, I saw the occasional ~33ms in both normal view and fullscreen.

Indeed on chrome 52, I'm not always on a 60fps basis.
I attached a test with the chrome fps debug tool on chrome 50, if it can be of any help.


One important thing though, I said previously that the custom VR toji build 52 (52.0.2711.0) is solving the issue.
But it's only true when I activated the webvr flags (which makes sense since toji probably had to fiddle with the requestAnimation frame stuffs since vr might require 90 fps).

Deleted: 50rightFull.jpg 41.7 KB

	50rightFull.jpg 41.7 KB View Download

Able to reproduce the issue on Windows 7 using chrome latest stable M50-50.0.2661.87 as well.

Bisect Information:
=====================
Good build: 50.0.2638.0 
Bad Build : 50.0.2640.0 

Normal CL:
https://chromium.googlesource.com/chromium/src/+log/50.0.2638.0..50.0.2640.0?pretty=fuller&n=10000

Tool Change Log: https://chromium.googlesource.com/chromium/src/+log/6dff929a11a7b4c752f20afb9f2cf5033031582d..18f47f8161cbdbe7c69ce3f52ee52e4acfbf9024

Unable to find the suspect from the above change log. Could anyone please look in to it and kindly assign to the concerned owner.

Thanks!

indonesia
Pada tanggal 22 Apr 2016 17.02, "brajkumar@chromium.org via Monorail" <
monorail@chromium.org> menulis:

Note that the built-in fps meter can skew measurements on some GPUs so please try turning it off.

If you can reproduce this, please record a trace[1] with the "cc.scheduler" category enabled and attach the result here.

[1] https://www.chromium.org/developers/how-tos/trace-event-profiling-tool

sunnyps: Based on the bisect, any chance this is related to 6ab38e4f06caa13bbcdfaa652109d114576c1cbe?

I looked at a trace and it looks like its skipping rafs in order to recover latency. Some latency recovery changes were made for M50 but none in the CL range from the bisect. I'll investigate some more.

A related (same?) issue might be this: https://bugs.chromium.org/p/chromium/issues/detail?id=607650.

Any progress on this?

Sounds like this is a scheduler issue rather than Blink's animation engine, removing label.

Sorry, I've been too busy to look at this. brianderson@ will be back soon and I'll ask him to take a look. Removing M-50 label (the label is for the version we're targeting a fix for, not the version with the bug) and making this Pri-2.

+ brianderson@

Indeed, it's probably the same issue as https://bugs.chromium.org/p/chromium/issues/detail?id=607650 too.

When I can reproduce on sketchfab, I can also reproduce on the other example (and vice-versa, when it works, it works in both case).

Out of curiosity -- under what condition does your sketchfab code (and therefore the other simple example) work? Is it only that special VR build that is working?

It's just different Computers.

Tests are done on same chrome version (was 50 and now 51), same os (windows 10), same url (both sketchfab and linked bug canvas timeline), even same nvidia drivers.
Only difference are the computers themselves. 

( Note that it's independant of "gpu power", as our most powerful gpu  is gtx980 and is ones of the 40fps, whereas lower gpu HW does get 60fps. )

Yes currently, the bug occurs on chrome 51 and canary 53.
The special VR build only works when I activate the webvr chrome flags in it.

If it can be of any help, we managed to fix the issue.
We had a small css animated element with a 0 opacity that somehow make the canvas rendering slower.
Since the element was hidden, we failed to notice it was still animated.

I don't really understand why a css element would hinder the performance of the canvas.

https://twitter.com/antumbral/status/768696820843196417 was the tweet that helped us (although I don't think it's specifically related to rAf since a setTimeout didn't help us for our bug)

Deleted: Sans titre.png 117 KB

	Sans titre.png 117 KB View Download

This appears to be fixed as per comment 29.