Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 14 users
Status: Fixed
Closed: Sep 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment
Chrome is janky compared to IE11 in HTML5 game
Reported by, Oct 17 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2190.0 Safari/537.36

Steps to reproduce the problem:
1. Visit in both Chrome and IE11
2. Wait for about a minute while the test runs and measures jank and dropped frames
3. Compare measurements between browsers

What is the expected behavior?
The test is designed to run on a 60 Hz display. It calculates dropped frames by simply the difference between the framerate and 60. Jank is calculated as delta time - (1/60), i.e. how much over 16.7ms the next frame arrived at. In other words it measures how late the next frame is, since jank will cause it to be late. Perfect jankless rendering will measure 0 dropped frames and likely <5ms max jank.

What went wrong?
Chrome measures: ~7 dropped frames, max jank: 9.4ms
These janks are visible while the test is running if you watch carefully.

IE11 measures: IE11: ~0 dropped frames, max jank: 3.8ms
It is visibly smoother.

Did this work before? N/A 

Chrome version: 40.0.2190.0  Channel: canary
OS Version: 6.3
Flash Version: Shockwave Flash 15.0 r0

Gamers are pretty sensitive to framerate jank, and it appears Chrome suffers from this. Users of the Construct 2 engine ( complain about this, e.g. see this thread:

We have done a lot of work to ensure our engine does not create lots of garbage. I believe the jank is caused by synchronous aspects of the JIT compiler in V8. IE11 apparently has entirely parallel JIT compilation which would also explain its superior performance in this test.

Comment 1 by, Oct 17 2014
BTW I tested on a high-end desktop: Intel Core i5-2500 @ 3.3 GHz, nVidia GeForce GTX 660, 8 GB RAM. It's a shame Chrome can't get smooth playback on a high-end machine and presumably the problem will only be worse on low-end systems.
Comment 2 by, Oct 17 2014
Status: Assigned
Jochen, feel free to further triage this one in the Web Platform Integration sub team, since getting rid of jank like this is high on your priority list.
Comment 3 by, Oct 17 2014
Please do something about this, it really causes a problem in HTML5 game development, there is a lot of random and sporadic stuttering on games that otherwise should have smooth movement and feel.
Comment 4 by, Oct 18 2014
It is annoying to have this happen. My PC can tear thru most any desktop game...but a mere flappy clone stutters. I'm also a user of the C2 engine, but I've noticed this in other contexts as well. Would love to see this fixed.
Comment 5 by Deleted ...@, Oct 18 2014
I have this also happening to me on my Intel core i7 4500u, 8gb ram win 8.1, nvidia geforce gt 745m laptop.
I also see this as a major bug in HTML5 game development.
I Kindly leave this with your highest attention.
Comment 6 by, Oct 19 2014
Also happening to me on any machines I test. This is crippling my game development as the effect seems to be far more pronounced when using some webGL shaders and/or lots of fillrate.
Comment 7 by, Oct 20 2014
can you share some information how you measure how many frames are dropped and jank?
Comment 9 by, Oct 31 2014
Just want to point out bug 422000 may be related.
I'm developing with Construct 2. Chrome Canary 40.0.2207.0 seems, subjectively, to jank significant less than the current stable. With my prototype, canary appears nearly as smooth as IE (and with lower cpu usage of course).
On my workstation the game looks pretty smooth. I am running the latest canary and see ~1 dropped frame and max jank of 4ms. I see almost all the garbage collection work being handled during idle time.

However, on an early thread we already discussed that jank in the game comes from the optimizing compiler. Yang, would idle time compilation help us in this case?
Not sure. Idle time compilation would only affect the code generation phase, which is pretty fast either way. To implement idle time compilation for the graph creation phase involves a lot more effort.
Canary is definitely a lot better on Windows. However jank is still bad on Android, which I filed separately as  bug 387675 . Using Chrome 39 beta on a Nexus 5 with Android 4.4.4, the same test measures 82 dropped frames with a max jank of ~50ms. It regularly janks for over 16ms and generally is not able to keep a solid 60 FPS.

Perhaps desktop systems are unaffected simply because they have the raw CPU power to get jank-related work out of the way quickly - if it's 4x faster than the Nexus 5 then the worst-case jank could be completed within a single frame time. I think it would still be worth testing Chrome on low-end desktop machines with weak CPUs to test if it also happens there. I'm afraid I don't keep any weak desktop systems myself.
Labels: Cr-Blink-JavaScript-API
we landed tons of improvements that should impact this (and at least for me this is not pretty smooth on canary).

could somebody verify that this is the case for you as well?
Status: Fixed
Sign in to add a comment