Why so much idle time?

[Dal]

Why is it that when profiling Babylon apps there seems to be so much idle time? I noticed this when profiling my terrain but when I tested other Babylon apps I get the same result. Attached is a profile for the Sponza demo.
It seems like all the work gets done in surges but then the rest of the time nothing is happening. Is there a way we can utilize that idle time?

[Rezoner]

That's typical for any game not just Babylon.js
As your game become more heavy on CPU usage the gaps will get smaller.
Game logic is being called 60 times per second - when the logic frame finishes its work there is not much left for it to do so the program goes idle and waits for the next frame.
If there were no gaps - it would mean that your CPU can't make it and the game is going below 60fps

In other words - it means that you can still throw more logic and content to the game because it has free computation power to handle it - which is a pretty good news.

[fenomas]

The browser sends out an event every time it's ready to display a frame of animation, and Babylon gets that event and renders a frame of animation, then waits for the next event. The fact that there's idle time in between just means the scene is successfully rendering at the target framerate. If you added more stuff to the scene, or more code to be run between frames, it would get done during the idle time.

[Wingnut]

Great topic, great answers!

The Gods of comedy were just SCREAMING at me.... when I read this line:

Quote

It seems like all the work gets done in surges but then the rest of the time nothing is happening. Is there a way we can utilize that idle time?

Although miserably difficult, I waited for others to seriously answer Dal's questions.  Now, that is done, and it's time for some laughs.

Dal... every boss, supervisor, and biz owner I have EVER known... says exactly those same words... about their people... seemingly once per hour. 

When I was in the US Air Force (9 years)... idle time was filled with a bottle of Spray'n'Wipe and a cleaning rag (it was called busy-work).  Maybe we could tell the framework engine to dust, mop and vacuum the scene when it's not rendering. 

Maybe we should do SETI ops during that idle time.  (Search for Extra-Terrestrial Intelligence) 

Ok, that's enough simulated comedy.  Sorry for the interruption.  Ok, no I'm not sorry... I'm still giggling.

[Dal]

@fenomas @Rezoner

The thing is, this pattern still occurs when I run on a mobile device that's struggling to get into double figures as far as the FPS is concerned...  that's why it struck me as odd.

[fenomas]

@Dal I believe that's down to how the browser is implemented. Like I said the browser is driving the loop (via requestAnimationFrame), so that's where the decision is being made how long to stay idle. If it was striving for absolute max FPS the browser could send the events more often, but that would likely drain the battery, heat up the phone, and make other operations (scrolling the page, background stuff outside the browser, etc) even slower. So I'd guess it probably just waits some minimum amount of time between frames regardless of how long the previous frame took.

If you really need to push performance, instead of using the default behavior (rendering from the browser's requestAnimationFrame) you could drive your own loop with setInterval and a delay of 0, or similar. That would probably cut the idle time a bit but arguably it wouldn't be a good default thing to do, for the reasons above.

[Dal]

@fenomas I don't think going faster will help much because there's no point rendering frames that can't be displayed...
What I am wondering though is, since we know that we will need a frame every 16.7ms to reach 60fps, if we have done rendering the current frame in 5ms, instead of drawing and returning and simply waiting for the next call, maybe we can draw and then do a bit of work on a long running tasks before returning. Each frame it just does a bit of the work until a time limit is reached, then stores the state, then does a bit more work the next frame etc. until it is done. Maybe that would give us a kind of "web worker" that doesn't have the limitations of actual web workers?

[fenomas]

@Dal Certainly you can do that - just add an afterRender handler or similar, and check how long the render took and then do some extra work as needed. But if the frame is finished rendering, what other work is there to do?

[Dal]

4 hours ago, fenomas said:

@Dal Certainly you can do that - just add an afterRender handler or similar, and check how long the render took and then do some extra work as needed. But if the frame is finished rendering, what other work is there to do?

Well, we could use this time for things like generating noise for heightmaps, processing images, perhaps even doing things like updating render textures and lightmaps. Basically anything in the engine where the position of the camera is not essential or can be predicted.

[fenomas]

Sure! That's what I do in my game - there are heavy long-running tasks like world generation, and every render or two I start a loop that works on such tasks until 3 or 4 ms have passed. Conceptually I just consider this part of the work being done each frame.