Any way to pause game/rendering to reduce CPU usage when idle

Questions
#1

I have a few Defold projects where the screen doesn’t change much—only when the user is actively giving input, or at certain time intervals. I’m wondering if there’s a way to save CPU usage during the 98% of the time when nothing visually changes and there is little to zero code running.

A release build with an empty collection and an empty render script still uses 5-9% of my desktop’s CPU.

That’s at the default 960x640 window size. If I set the window size down to 50x50 then the CPU usage goes to 1% and if I roughly double the area of the window, the CPU usage roughly doubles as well, so I’m assuming most of the CPU time is it clearing and redrawing (nothing) every frame. But that’s using a render script with no code in it at all, so I guess there’s no way for me to actually pause rendering?

2 Likes
Non-game application on this engine?
Pause rendering, save battery
#2

Correct. But perhaps you could reduce the update frequency to 1 FPS or render to a render target and use that while nothing is changing.

4 Likes
#3

What if set flag in render script. And if flag is true do not call render commands. Or make something like non continuous render https://github.com/libgdx/libgdx/wiki/Continuous-&-non-continuous-rendering
It should work

5 Likes
#4

That’s what I figured, darn.

I tried reducing the frame cap to 15, and that made a pretty big difference (lower numbers didn’t seem to work). But I don’t really want a low framerate when the player is doing things, and there isn’t a way to change that at runtime is there?

Yeah, I would use a render target when there are a lot of things on screen that aren’t changing. Right now I’m just testing with nothing on screen at all.

Would this have any priority as a feature request? It seems like it could reduce battery usage to almost zero for solitaire games and simple strategy games, and fit with Defold’s theme of good performance.

@d954mas Yeah! That would be exactly what I want. To be honest I thought that not doing anything in the render_script update would be like this, but apparently not.

1 Like
#5

Try to put a master controller collection proxy on top of everything, with an input controller on top of that. Then you can throttle the update rate of the master controller to 1 while there is no user input, and put it back to whatever you want when active. I don’t know if that would actually help though since there are constantly other things going on in the engine. Try to strip the engine of features like physics and audio too to see what idle CPU impact they have? Also in your scripts it would be useful to test if having no update helps with CPU, then handle everything by message passing only instead with only a single handling on input. :thinking:

Don’t forget about msg.post("@system:", "set_update_frequency", { frequency = 60 } ) too.

1 Like
#6

What does the profiler say? Where does the engine spend its time?

2 Likes
#7

For the sake of science: (these are the peak frames)

18_no%20vsync%20or%20frame%20cap
Screenshot 2019-12-21 14.38.18_no vsync or frame cap.png1500×837 120 KB
48_no%20vsync%20or%20frame%20cap
Screenshot 2019-12-21 14.38.48_no vsync or frame cap.png749×837 93.3 KB

This is with vsync off (but my graphics driver might be enforcing it anyway?) and no frame cap. The time is mostly spent in “Engine.Sim”, with a tiny bit in “Profile.Draw” (which I guess is just to draw the profiler and not really part of the test).

The only difference between the two screenshots is the X resolution is doubled in the first one. The CPU usage seems to scale linearly with the number of window pixels, though the engine time spent changes by a lot more.

Pkeod: Yeah, I’m talking about the base engine running cost. My previous test was with a completely empty bootstrap collection and a render script with no code in it, checking the CPU load via the windows task manager.

Hmm, I will try stripping some things, it would be interesting to see if that makes a difference.

Ah! I didn’t know about that message, thanks. On first test, it doesn’t seem to work quite the same way as changing the game.project setting and rebuilding, but I’ll have to test more.

At this point I’m pretty much just testing this out of curiosity. I realize that putting the whole engine into “standby” mode isn’t something that game engines support (Unity does not for example), only a couple lower-level frameworks do.

1 Like