Chromium and its cap of 60 fps

[Chris Turnbull]

Hi there

I've recently discovered node-webkit, and am looking to use it to make a video-game written in webGL. Without wanting to digress too much in this thread, long story short, I'm looking to put a lot of time and effort into this, but right now I've only just started. There are some very pretty looking cubes and spheres flying around on my screen, but that's about it ^_^;;

One thing I've noticed about Chromium and WebGL is that it seems to be capped at 60fps.

Now that's probably sensible; it's overkill for reading text and looking at animated .gifs and the like. Even watching YouTube videos don't come close, as YouTube caps them at 30fps.

However the high-end PC market is moving towards 120fps. You can get 120fps monitors running at 1080p, and (depending on the complexity of the game in question) modern systems can run video-games at that speed.

OK, so I'll be the first to admit that being capped at 60fps is not exactly a show-stopper. Node-webkit adds a ton of features, is definitely worth using, and I know there's always probably going to be limitations.

But if it's just a number or constant in Chromium's code, would it be possible for us to have the option to increase it when using node-webkit? It would be nice if a video-game written using WebGL and node-webkit did not have any limitations compared to a video-game written in any other language/toolkit.

Hopefully there's no harm in asking, so I just thought I'd ask ^_^;;

[Sean Nicholls]

> One thing I've noticed about Chromium and WebGL is that it seems to be
capped at 60fps.

Can the human eye actually discern anything greater than this?

From what I understand the human eye is unable to discern between
images greater than ~62 FPS (16ms per image).

Any extra frames drawn past 60FPS seems wasted (except in rare
instances due to persistence of vision)

[Chris Turnbull]

To give you a short answer: yes it is possible.

To give you a slightly longer answer: It's difficult to tell the difference between 60 and higher, but not impossible depending on what you're looking at.

For example, a good example of the differences that fps can make can be found at http://boallen.com/fps-compare.html. You can clearly see the difference between 15 and 30, and 30 and 60. Event if you look closely at the edges of the cube from last example running at 60 fps, you should still be able to see artefacts on the edges.

All that being said, I'm not too worried about a poor simulation of a spinning cube. I think most of people would agree with you that anything drawn past 60 is a waste and would probably turn up the graphics details instead, as long as they could get their game running at 60 fps.

But I'm more worried that some people will see any kind of artificial cap on their system as bad in principle.

So... is it an artificial cap? I just thought I'd ask.

[zar...@gmail.com]

> So... is it an artificial cap? I just thought I'd ask.

I would be interested to know as well, not as much to have final animation above 60 FPS, but more for bench-marking purposes.

When frame-rate is uncapped, it's very simple to see how much headroom you have (or not), measure the individual impact of rendering options, etc. It gives a very simple indicator when developing.

Eric