I have been doing some work with the canvas using JavaScript and I have noticed the FPS in Chrome seems to cap out at 60fps until such point as opening the inspector up (the dev tools accessed from right clicking and clicking "Inspect Element").
If I run my own code in other browsers there is no FPS issues, likewise if I run in Chrome when the inspector tools are open there is no issue, it instantly shoots up to 120 frames per second.
As a means of showing a practical example, take a look at this page: .html
If I view this page without my inspector tools open, the FPS graph shows between 40 and 60 frames per second. However, as soon as the inspector is open, the FPS instantly jumps to 120 FPS again and is visually and physically more responsive.
I'm really struggling to understand why this is and ideally would like to have my code running as if the inspector window was open. As essentially the amount of time being given for processing seems to be dropping by a substantial amount.
Is this a known limit of code being executed in a non-debugging environment?
Any insight would be much appreciated, thank you :)
I have been doing some work with the canvas using JavaScript and I have noticed the FPS in Chrome seems to cap out at 60fps until such point as opening the inspector up (the dev tools accessed from right clicking and clicking "Inspect Element").
If I run my own code in other browsers there is no FPS issues, likewise if I run in Chrome when the inspector tools are open there is no issue, it instantly shoots up to 120 frames per second.
As a means of showing a practical example, take a look at this page: http://mbostock.github.io/d3/talk/20111018/collision.html
If I view this page without my inspector tools open, the FPS graph shows between 40 and 60 frames per second. However, as soon as the inspector is open, the FPS instantly jumps to 120 FPS again and is visually and physically more responsive.
I'm really struggling to understand why this is and ideally would like to have my code running as if the inspector window was open. As essentially the amount of time being given for processing seems to be dropping by a substantial amount.
Is this a known limit of code being executed in a non-debugging environment?
Any insight would be much appreciated, thank you :)
Share Improve this question asked Dec 9, 2013 at 23:01 user1243584user1243584 9- 2 How are you measuring FPS? Which "FPS graph" are you referring to? – user229044 ♦ Commented Dec 9, 2013 at 23:04
- 2 It might just be that with the inspector open the page is smaller and quicker to draw. Resizing the browser window in that example seems to have the same effect as opening the inspector. – sbking Commented Dec 9, 2013 at 23:04
- The fps measure tool of Chrome is very expensive, it seems both to slow down display and to create quite some garbage (which cause frame miss) : do not use it, rather measure time / fillText by yourself. – GameAlchemist Commented Dec 9, 2013 at 23:06
- Did you activate the option "Force accelerated positing" in the dev tools? – ComFreek Commented Dec 9, 2013 at 23:08
- 2 @Cuberto - you're right, it did the same for me, after further investigation it seems as though it may be due to having two monitors setup (see my answer I posted) – user1243584 Commented Dec 9, 2013 at 23:13
2 Answers
Reset to default 1After experimenting a bit further after reading Cuberto's findings, it seems that this may be a bug with Chrome and dual monitor setups.
As Cuberto suggested, I tried resizing my window a bit smaller, and this made the FPS shoot back up. Even if didn't have the screen maximised, but still had it spanning most of the screen it would be at max FPS.
Curiously, I disabled my second monitor and then put Chrome back into the maximised state, and it was fine.
As soon as I re-enabled my second monitor the FPS shot down again, so it would appear this is the problem.
Upd: it seems someone else has had this same problem with dual monitors (see ments): Why would Chrome cap frame rate at 30fps?
This is a question of resolution. When opening the inspector in chrome, you're basically changing the resolution of the current window, which means it runs faster. That's all folks.