Open Bug 828189 Opened 12 years ago Updated 8 months ago

mozRequestAnimationFrame doesn't tick very precisely in Firefox 18

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
18 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

People

(Reporter: bernhard.robert.pichler, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 Steps to reproduce: mozRequestAnimationFrame(onFrame); function onFrame(t) { console.log(t); mozRequestAnimationFrame(onFrame) } Actual results: [10:53:16.183] 1357725196183 [10:53:16.190] 1357725196190 [10:53:16.220] 1357725196220 [10:53:16.221] 1357725196221 [10:53:16.240] 1357725196240 [10:53:16.248] 1357725196248 [10:53:16.262] 1357725196262 [10:53:16.278] 1357725196278 [10:53:16.305] 1357725196305 Expected results: The times logged to the console should have a delta of ~16-17 ms on my 60Hz screen. But in fact they have a delta ranging from 1ms to 30ms. Therefore all animations look very bad.
Can you please attach a full testcase and not only a snippet ?
The snippet is the full test, there is nothing else. Of course you will use mozRequestAnimationFrame in a real web-app in combination with canvas or something like similar. Here is the code on jsfiddle: http://jsfiddle.net/49YD8/ You can look at a "real world" example and how awful it looks compared to Chrome or IE9 here: http://www.dartflash.com/demos/performance/performance.html The JavaScript of this example is compiled from another language, so don't be surprised. But the root of all problems is the code snipped above.
Component: Untriaged → Layout
Product: Firefox → Core
Is this specific to 18, or are you seeing the same behavior in 17? If you see the same behavior, I suggest you try a nightly build with bug 731974 fixed.
Summary: mozRequestAnimationFrame broken in Firefox 18 → mozRequestAnimationFrame doesn't tick very precisely in Firefox 18
Flags: needinfo?(bernhard.robert.pichler)
I don't have Firefox 17 on any PC anymore, so i can't test it. But i can say that i didn't noticed problems with mozRequestAnimationFrame on Firefox before. If there was an issue before, then it was definitely not as bad as it is now.
Flags: needinfo?(bernhard.robert.pichler)
(In reply to bernhard.robert.pichler from comment #4) > I don't have Firefox 17 on any PC anymore, so i can't test it. All the old versions are available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ Just select your OS and language.
The reason I ask is that I'm not aware of any changes in requestAnimationFrame behavior between 17 and 18.
Yes you were right, the small test i did shows similar numbers in Firefox 17. The interesting thing is that animations look pretty smooth in Firefox 17, but they are not smooth at all in Firefox 18. Based on the time of requestAnimationFrame every animation should be jerky. However, as Boris said earlier it really is the same problem as bug 731974. Obviously it is still an issue. Thank you very much for your help.
But 731974 is fixed in 20, not in 18... If you're willing to try a build from http://nightly.mozilla.org/ and see how things look there, that would tell us whether it fixed the problem you're seeing or not. I can totally understand if you don't want to spend the time doing that, of course!
Okay i understand, sorry for the misunderstanding. If someone has FF 20 already it is pretty obvious when you look at the numbers. Anyway, if i have some spare time next weekend i will give it a try.
I have downloaded the latest nightly build (21.0a1 2013-01-11) and requestAnimationFrame works better compared to Firefox 18. But it's far from perfect, please look at the numbers below. I show the delta-times from one frame to the next in milliseconds: Firefox 21.0a1 2013-01-11: 14,13,17,17,21,14,16,16,18,18,16,20,15,14,16, ... Firefox 18: 14,15,30, 0,14,14,14,21,16, 7,15,16,19,17,13, ... Chrome 24.0.1312.52 16,17,17,16,16,17,16,17,16,17,17,17,16,17,17, ... IE 10 (already supports the new sub-millisecond resolution) 16.669, 16.718, 16.638, 16.514, 16.666, 16.686, 16.683, ... I hate it to say, but IE10 works best.
OK. The main question I have is whether the actual visible behavior (the thing you say got worse from 17 to 18) is any better in the nightly. Vlad, see comment 10?
One other question. If, instead of logging the argument to the function, you log the values of performance.now() (in Chrome you'll need to use performace.webkitNow()), what do you see? That will differentiate between noise in firing the callback and noise in the passed-in argument (which somewhat unrelated to when the callback fires).
Same test with performance.now(); Firefox 21.0a1 2013-01-11: 4.25, 17.99, 16.00, 19.4, 14.2, 16.49, 18.02, 21.19, 13.77, ... Firefox 18: 23.58, 7.09, 13.32, 15.00, 15.67, 16.3, 17.1, 17.56, 22.03, ... Chrome 24.0.1312.52: 16.99, 16.99, 15.99, 16.99, 16.99, 16.00, 17.00, 16.99, ... IE 10: 16.95, 16.44, 16.63, 16.70, 16.75, 16.62, 16.67, 16.75, ... Again Firefox shows the worst results.
Answer to comment 11: Yes the animation looks a little bit smoother in Firefox nightly compared to Firefox 18. But it is not as smooth at it is in Chrome or IE (as the numbers show too).
Would you mind attaching the testcase you used to generate comment 13, just so we're looking at the same thing?
Thanks. Ok, yeah, that's what I was looking for. I see quite different behavior on Mac (in particular, Chrome is much bouncier there), so this sounds like more Windows-specific timer fun...
Status: UNCONFIRMED → NEW
Ever confirmed: true
jQuery is seeing similar behaviour in their detailed analysis on switching to rFA for animations: https://github.com/jquery/jquery/issues/3143 :milan recommended to ni? :bz
Flags: needinfo?(bzbarsky)
The jQ team added more details in a bug they just filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1278408
I made this CodePen to help visualize the timestamp jitter: https://codepen.io/joliss/pen/ZObOPm In Chrome, the line is usually straight, whereas in Firefox we get jitter. See the screenshots :m_gol and I posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1278408
All the discussion in this bug predates firing rAF from vsync, so I'm not sure how relevant it is at this point. As far as bug 1278408 goes, see bug 1278408 comment 1278408.
Flags: needinfo?(bzbarsky)
(In reply to Boris Zbarsky [:bz] from comment #21) > All the discussion in this bug predates firing rAF from vsync, so I'm not > sure how relevant it is at this point. Then is this bug still valid at all?
I don't know.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.