1427603 - Requestanimationframe inconsistent framerate (drops from 60 to 30)

Status: UNCONFIRMED

(Core :: Graphics, defect, P3)

Description

[Allan]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30

Steps to reproduce:

1 - Open Firefox on Windows (this problem doesn't happen on Mac in my tests).
2 - Use "requestAnimationFrame" on your javascript code and measure the time.
3 - Wait some minutes. In a simple example it took 15 minutes to begin happening.
4 - If you have a 60Hz monitor for example, it will begin on 60FPS (+/- 16ms) properly and without reason it will drop to 30FPS (+/- 33ms).

* A simple example: https://jsfiddle.net/xyaucws8/
In my 60Hz monitor it begins on 16ms and after 15 minutes it returns 33ms.

* Three.js examples: https://threejs.org/examples/
The more complex the example, the earlier it happens.

* Three.js specific example: https://threejs.org/examples/webgl_animation_cloth.html
It took 1m28s to begin happening in my test.

I really suggest test it on a example from Three.js framework, because the simple example takes a lot of time to happening (it can take more time that I measured, because I believe it depends the PC configuration). I only tested in a simple way to comprove that it happens in any situation.


Actual results:

If you have a 60Hz monitor for example, it will begin on 60FPS (+/- 16ms) properly and without reason it will drop to 30FPS (+/- 33ms) after some minutes.


Expected results:

If you have a 60Hz monitor for example, it should keeps 60FPS (+/- 16ms) all the time.

Comment 1

[Emil Pasca [:emilpasca]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

I had tested this issue on Windows 10 x64 with latest Firefox Release(57.0.4) and the latest Nightly (59.0a1-20180104220114) and haven't manage to reproduce the issue.
I had tested this on two different monitors (60Hz), after loading the provided examples in the browser and waiting for several minutes (>15 minutes), in any examples the FPS remained the same (60FPS, +/- 16ms).

Since this issue might be due to your PC configuration, could you please add the information from "about:support" page in order to investigate this further?
Also could you please retest this using a new clean Firefox profile (https://goo.gl/x4EdXd), maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/fPLNDn)? If you also find the time please test this using the latest Nightly build (https://nightly.mozilla.org/) to see if there are any differences.

Thank you.

Comment 2

[Brian Birtles (:birtles)]

Hmm, this is likely not DOM: Animation (which is for declarative animations as opposed to imperative use of requestAnimationFrame). This might be a gradual memory leak that slows us down such that we are no longer able to meet our 16ms deadline (perhaps WebVR-related?) or it might be something else. Moving to DOM for now.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

More likely gfx, which trigger animation frames.