Demo FPS 20fps while potential FPS 60fps

[BeanstalkBlue]

Running the instance Demo both from the babylonjs.com website and locally:

I see potential FPS in debug overlay showing ~60 FPS.

Actual FPS is ~15 FPS.

I tested this in both Chrome and Firefox on both Linux and OSX.

I tried removing various parts of the code. Reducing instance count to 10, removing collision tests from all objects. The FPS rises somewhat but the problem persists.

I tried checking out the v2.5.0 tag in case something in latest was causing the problem. The problem persists.

I think this may be due to BabylonJS depending soley on requestAnimationFrame for update/draw logic (which creates several problems actually, but I created a separate post to address that). I assume there must be something wrong in the update logic, but I am new to BabylonJS.

 

Is anyone else seeing a low FPS number on the babylon website?

 

 

See attached screenshot where render and frame are only 5ms and 8ms (potential FPS is 128) yet FPS is only 40!

[Dad72]

I am at 60FPS on all demos. May be your GPU or CPU is not powerful enough. 

[BeanstalkBlue]

No, see the screenshot.

FPS is 40 but potential FPS is 128. Update/draw are not being called as often as they should. It's a bug.

In the screenshot Frame time is only 7.8ms. That implies 128 FPS is possible.

Also, this is a Skylake core i7 machine, it's fast enough to do 100 draw calls with no texturing or shadows as per the screenshot (haha).

[Dad72]

You had to have 60FPS which is the max of the render loop. On my PC, I'm a 60 on all demo, so I do not think there's a bug with Babylon.

Maybe your computer is using a lot of processes going on and actually slowing down.

[BeanstalkBlue]

No. You are missing the point.

Maybe your browser with requestAnimationFrame is providing the correct timing to Babylon and in my browser it is not.

I just tested on another computer (a Macbook Air) using Chrome. Using debug overlay I turned off features until the stats show less than 6ms per update/draw. So FPS should be at 60 (debug stats show potential FPS is 150).

This has nothing to do with computer speed or processes in background. Stats prove that FPS could be at 60 if babylon was calling render often enough, but it isn't. There is a bug somewhere.

Is it possible for me to override update/draw timing logic in Babylon without modifying/recompiling babylon?

[Dad72]

Maybe you are right.

[BeanstalkBlue]

See screenshot attached to this post, this one makes it more obvious.

Rendering a black screen. Potential FPS is 1100+. Actual FPS only 24 FPS

[aWeirdo]

something is clearly wrong, but i'm not sure it's babylon.

this is on a intel i5 4670K 3.40 GHz & Nvidia GTX 760 2GB, with several other heavy programs running in the background..

[davrous]

Hello,

This is not a problem related to requestAnimationFrame. requestAnimationFrame is definitely the way to go to manage the render loop. 

The potential FPS is based on the time we need to render the frame. If you're rendering a frame below 16ms, this means you could potentially display more than 60fps if the browser and/or the screen support it. Which is the case for WebVR for instance allowing to go up to 90fps. 

Still, if the real FPS displayed is inferior to the potential FPS, this means that your GPU could draw more stuff but you're CPU bound. The computation done on the CPU side to update the scene (mainly matrix computations) is taking more than 16 ms which explains that your FPS is below 60 fps.

You shouldn't misinterpret the values we provided in the debug info. To conclude, if the potential FPS > FPS and FPS < 60, this means that you're CPU limited. I'm sharing a bit how to check that in this article: https://www.davrous.com/2014/02/19/coding4fun-tutorial-creating-a-3d-webgl-procedural-qrcode-maze-with-babylon-js/

Try to use F12 of your browser to measure the performance. You should see that the JavaScript part is taking much of the time.

David