Update Loop Question

Is it possible to pause/stop/etc the render loop and only update/render on request?

If it is not possible, are there any alternatives?



P.S. Trying to make some time to get back to dev… but we shall see…

1 Like

Make a boolean paused and set it to true or false when you want to pause it. Then, in the update loop, do this:

public void simpleUpdate(float tpf) {
if(!paused) {
// your code here
} else {


Hope it works!

The ideal situation would be to not have to stop the update loop and be able skip the frame render unless specifically called.

I’d still like the updates against the scene graph to happen.

If I’m not mistaken, render is called after simpleUpdate no matter what.

Anyone know of a way around this? If I forego using simpleApp, can I get around this?

Thanks again!


1 Like

Well, you can cull the rootNode. Culling is basically telling the graphics card to not render a spatial. This is used for objects out of range to speed up.

The only problem is, when you cull the whole scene, you will see nothing. But I don’t have any other solution.

To do that just type:


To make it visible again type:


Hope it helps in some way!

I may be able to fake what I am trying to do using culling and rendering off-screen. /shrug

Essentially, I want to limit render updates to only when something in a relatively static scene has changed. Even better would be to limiting the area of the screen re-rendering to only that part that has actually had a change occur.

Both may be doable by rendering off-screen and dividing up the screen into multiple quads. And only re-rendering each section when something in it has changed.

If anyone can think of a simple approach to this, any insight would be appreciated.

1 Like

Rendering off screen may be the only approach that works well. When the rendering is not done then the window does not update so will continue displaying whatever was last there… including other pop-up windows, etc… So you probably at least want to render something.


Awesome… This is the approach I’ll take then. Do you think dividing up the screen into smaller, separate rendered areas and only re-rendering the portions that change would have any significant impact on frame rates for mobile devices? I know that setting this up would be a pita and I’m not sure I want to attempt it without at least hearing that it has the potential of making a difference.

This, again, is geared towards 2d (gui rendered) gaming for mobile devices.

1 Like

Sounds like overkill. It remains to be seen if any of it will matter… so might as well go with the easiest and most lightweight version.

It should be possible to tweak the JmeContext implementation so that it only renders on request, for example. The update loop would still run.
For example in the SDK editor, the canvas / AWT panel implementation will update at a lower rate and stop rendering when the SceneViewer window is closed, to reduce CPU / GPU usage.

1 Like

This would be a neat addition to JME (the ability to choose the update type… auto/requested/etc)… I know it probably doesn’t fall into dev plans as they stand atm, but would be ultra helpful for mobile gaming.


Hi there, I know this is an old post, but has anything changed to make tOnegOd’s request possible? I have a similar situation where the scene is mostly static. And due to the nature of the game loop the CPU is under constant load, causing CPU fans to scream. If not is there a way you can recommend that I can pause the update loop myself and only continue if something in the scene changes?

Don’t do so much on the update loop.

Without the update loop, your game doesn’t render… screen doesn’t refresh, etc… Anything painting over your window will leave doo-doo trails.

99.99999% of the time, this is a misguided request. The other .000001% of the time, it’s such a specific requirement that the person who needs it can figure out how to hack the engine to support it locally for their one super-secret gov’t project that somehow requires it.

Or just use vsync and/or limit the framerate to 10

1 Like

True. That’s definitely an option also.

…but it sounds like he’s doing a ton of stuff on the update loop and if you only want to do that stuff periodically then only do it periodically and let the update loop run.

public void update( float tpf ) {
    if( my stuff has changed ) {
        do the expensive stuff

Even better: have your own thread(s) and only enqueue the scenegraph changes as they appear.

But if he runs a game uncapped every CPU might Scream at 300 fps +

True. I run with vsync by default now so I forget others do the crazy way sometimes.

Thanks everyone for the replies. I tried the vsync option but it did not make much of a difference. Also, I don’t really do anything in the update loop at all.

To give you a bit more context about our application. We have JME embedded in a NetBeans Platform application with AwtPanels ect. The scene is then populated by multiple geometries (Buildings ect). Users can navigate the scene with the keyboard and mouse, but in most cases they just look at it and the picture is static. Frame rate is set to 60 but I have not yet tried the vsync option. We have different threads creating the Geometries and calling enqueue when necessary. So I don’t think it is a threading problem.

I suppose the next step is to run a profiler to see which part of the update loop is causing the increased load.

Ok, with some further testing it seems I was wrong thinking is the update loop causing the problem. It is the AwtPanel with PaintMode.Accelerated that is causing the increased CPU load. I’ve tried the PaintMode.Repaint option but then the screen flickers.

I recommend you trade AwtPanels for Lemur, so you get integrated interface instead of mixing the two :slight_smile: