Reducing CPU usage possible..?

[Carsten Schmied]

I checked out tripleplay 2.0 and wanted to play around with the demo. The main screen shows all the available sub-demos.

If I look at the CPU usage it is constantly pretty high. Even when the demo-window is minimized. Basically on CPU core is always maxed out.

I guess this is the same on Android and iOS because they use the same rendering loop principles, correct? Seems quite wasteful on battery driven devices.

All UI toolkits I know are basically doing nothing CPU wise when nothing is going on. Which I like a lot :)
I know TriplePlay UI is not like all the other UIs out there. Still, I was hoping for UI-only screens (not real game screens) to have a CPU usage of basically 0%.

Is it in principle possible to create some GUI heavy screens that use almost 0% CPU when nothing happens? Is there some demo code somewhere?

Is it possible to add a "Pause" button to your game that halts all rendering and results in 0% CPU usage?

For Android/iOS games, does this happen automatically when in the background or the screen is "off"?

[Michael Bayne]

On Wed, Apr 15, 2015 at 10:11 AM, Carsten Schmied <carsten...@gmail.com> wrote:

If I look at the CPU usage it is constantly pretty high. Even when the demo-window is minimized. Basically on CPU core is always maxed out.

On what OS? That's weird, because it should not render if the window is minimized. Maybe LWJGL changed in that regard.

I guess this is the same on Android and iOS because they use the same rendering loop principles, correct? Seems quite wasteful on battery driven devices.

PlayN and TP are designed for making games where things are animating all the time. Thus it's not worth the extra effort and complexity to support dirty region tracking and deferred rendering when you're just redrawing everything every frame anyway.

Is it in principle possible to create some GUI heavy screens that use almost 0% CPU when nothing happens? Is there some demo code somewhere?

With PlayN 2.0, you have total control over rendering. So you can choose not to render on a given frame. PlayN just emits a signal every frame (calls a method in your game), you choose whether or not to update your simulation or redraw the screen in response.

However, TP does not make it easy for you to know that something has changed on a given frame, because as I said earlier, it assumes that you're making a video game where things are animating all the time.

Is it possible to add a "Pause" button to your game that halts all rendering and results in 0% CPU usage?

Sure, that would be super easy. The simplest thing to do would be something like this:

public class MyGame extends SceneGame {

  private boolean paused = false;

  // etc.

  @Override protected void paintScene () {

    if (!paused) super.paintScene();

  }

}

If you set paused to true, no painting will happen. Whatever the last frame was before you paused will continue to be displayed. Or you could override the update and paint methods if you wanted to disable updates as well as painting:

  @Override public void update (Clock clock) {

    if (!paused) super.update(clock);

  }

  @Override public void paint (Clock clock) {

    if (!paused) super.paint(clock);

  }

But beware of overriding update() because TPUI relies on that for some stuff. Mostly it acts in response to input events, which will still come in and, for example, allow the unpause button to work, but since you're not painting when you're paused, you're not going to see that button transition to the armed state when you press it because you're not drawing anything.

For Android/iOS games, does this happen automatically when in the background or the screen is "off"?

When the screen is off, or your app is in the background, it does not render. You don't have to do anything special to make that happen.

-- m...@samskivert.com

[Carsten Schmied]

Thanks!

It's Linux Mint 17.1

I understand that PlayN and TP are designed for making games where things are animating all the time.

Still I wonder if one needs a lot of complexity or things like dirty region tracking to have a UI-only (non-game) app that can be told to not render all the time but only in response to some action, like mouse hover and mouse press. There would be no dirty region tracking but everything is repainted after any action. On top the user can trigger a full repaint programmaticly.

I am asking because I think it is a shame to restrict TPUI to game development. I think it would be great just as a general purpose multi-platform UI if one could tell it that there is no need to warm-up the CPU because nothing is animating and nothing ever will. The tripleplay demo is a good example of many pure UI screens without any animations.

But you are the expert. I cannot tell how difficult it would be. I hoped it would be only small changes that could allow using TPUI for other things but games without wasting CPU.

[Michael Bayne]

On Wed, Apr 15, 2015 at 11:30 AM, Carsten Schmied <carsten...@gmail.com> wrote:

I am asking because I think it is a shame to restrict TPUI to game development. I think it would be great just as a general purpose multi-platform UI if one could tell it that there is no need to warm-up the CPU because nothing is animating and nothing ever will. The tripleplay demo is a good example of many pure UI screens without any animations.

It's true that you could get away with a very rough notion of "dirtiness", basically a single bit saying "did anything change this frame? if so, repaint everything".

That probably wouldn't be terribly hard to wire up, but it would be even easier to just repaint on every frame that processed any input events. You can even do that without any support from TriplePlay. Instead of the changes I proposed earlier, just do something like:

class MyGame extends SceneGame {

  private boolean needsPaint;

  public MyGame (Platform plat) {

    super(plat, ...);

    UnitSlot needsPaintSlot = new UnitSlot() {

      public void onEmit () { needsPaint = true; }

    };

    plat.input().mouseEvents.connect(needsPaintSlot);

    plat.input().touchEvents.connect(needsPaintSlot);

    plat.input().keyboardEvents.connect(needsPaintSlot);

  }

  @Override public void paint (Clock clock) {

    if (needsPaint) {

      super.paint(clock);

      needsPaint = false;

    }

  }

}

Input events are dispatched before painting, so any input events would be processed and flip the needsPaint flag before it came time to paint for that frame, at which point the (presumably changed) scene graph would be painted, and then no more painting would be done until another input event came in.

It's clearly a bit hacky, but it could get you what you need without requiring massive code changes to TriplePlay.

-- m...@samskivert.com

[Carsten Schmied]

I added those changes to TripleDemo. It works as expected for simple things like button presses where the UI is correclty updated in a single paint call.

For things with animations I have to constantly "arm" the painting by sending signals (i.e. moving the mouse). For example the menues - I need to move the mouse after the click for the menue to appear. Probably because you use many paint cycles to fade them in, instead of simply showing them.

Demos like Flickr work perfectly since I need to move the mouse anyways for scrolling.

The funny thing is, this modification gives you actually insight into the behind the scenes stuff in PlayN since you can pause everything by taking your hand from the mouse - and resuming everything by moving the mouse. Take the InterpolatorDemo for example. You can trigger "All" interpolations...move the mouse a litte...stop...resume...etc.
The interesting thing is, that the animation process is not skipped but seems to be queued up and resumes once the painting resumes. I expected to see the "final frame" after pausing and resuming, but it seems animations are not skipped.

This is all quite interesting and it is already working 95%. To make it work 100% one could add a flag to TPUI to skip all animations and use only one paint cycle for all visual changes. Or one could change the "needsPaint" mechanism to allow painting in the rare case of animations until they are completed. TPUI and PlayN are really cool projects.