I'm new to Processing but very impressed. I have had more fun in the last couple of days than in a couple of years of my normal job

I have put together a little program that has a mostly static visualisation but when I run it then my CPU seems to be very active, which makes sense because it's presumably redrawing everything repeatedly.

I tried to improve things by calling noLoop() in setup and then draw() when I need something repainted but there is a problem here. My visualisation has some short-lived animations in them so I would like the draw() code to be able to trigger another frame if the animation isn't complete (by calling redraw()?). But redraw() seems has no effect if called from within draw(), so either my animation stops after the first frame if I call redraw() or skips straight to the end if I call draw(), because the intermediate images aren't being rendered.

Does anyone know a good trick to do this, or is this something that I have to solve outside the Processing framework (e.g. by defining my own 'redrawNeeded' flag)?

I thought it would be clear enough from the explanation, but here is a test program that shows my problem. If I take away the noLoop() and the redraw() calls then it works - when you click the mouse the randomly place text slowly fades in. But once the 'animation' part is finished it still chews up 20% CPU on my dual CPU desktop (not a bad one, either!) even though nothing is happening.

As I often work on my laptop when travelling on the train this means that I have less time to have fun with Processing before my battery is empty as the fan kicks in very quickly

With the commented redraw() call nothing happens. If I replace this call with a draw() then it skips the animated fade and simply shows the finished visualisation.

It would be perfect if redraw() could simply trigger a new call to draw (in the normal way) whenever the current frame has been rendered. I'm not quite sure why that's not the case, but I'm sure this must be a common problem.

At the moment the only way that I can see to make this more efficient is to leave it in 'loop' mode and implement my own check to decide whether to redraw the visualisation or not, but that seems like something that a framework like Processing should help with and as a beginner I just thought that I missed something.


PFont font;
int seed = 0;
int trans = 0;

void setup() {
 size(600,600);
 font = loadFont("Verdana-20.vlw");
 noLoop();
}

void draw() {
 background(128);
 Random rnd = new Random(seed);
 for (int i=0 ; i<200 ; i++) {
   smooth();
   textFont(font);
   fill(10, 10, 100, trans);
   text("A Test", rnd.nextInt(width), rnd.nextInt(height));
 }
 if (trans < 128) {
   trans++;
   redraw(); // what to do here?
 }
}

void mousePressed() {
 seed = mouseX ^ mouseY;
 trans = 0;
 redraw();
}

can't you just call noLoop() again when the animation's finished?

i had the same problem with a puzzle i wrote. when you were dragging pieces into place you had to redraw everything but if you hadn't picked up a piece or weren't moving the mouse you didn't need to. jumped through all sorts of hoops and am not sure it's done in the best way now but...

http://www.koogy.clara.co.uk/puzzle2/

source code included but is lacking comments (i tidied it up for version 3, at least i hope i did). beware the sounds as well, version 3 had visual feedback but 2 is quite noisy, especially when (if!) you finish.

edit:
actually, the noLoop thing is exactly what blindfish suggests, specifically here:

  if (trans < 128) {
    trans++;
  }
  else {
    println("end");
    noLoop(); <- animation is finished so disable looping
  }

PaulC wrote on Oct 28^th, 2009, 3:49am:

Well, that's redraw()
I haven't followed closely this thread, so I am not sure what is your issue with it.

[EDIT] I re-read your first post, and I see a problem: you are not supposed to call draw(), it is called by Processing. That's what redraw() is made for.
You should change your logic, so there is a separate function which call redraw() and find out if another is needed after this one.

You can also just let the drawing calls to be called at normal rate (which you set, of course), and if there is nothing to do, just exit draw() early, not changing anything in the display (no background() call, etc.). Thus you have a timer ticking, and you can control the sequence of events and draw calls.

PhiLho  wrote on Oct 28^th, 2009, 4:00am:


I realised that I am not supposed to call draw() (that's just plain ol' recursion) but redraw() doesn't work from within the draw() method. Where else can I call it from Putting it in another method that is then called by my draw() code obviously won't make any difference.

So the conclusion is that only way that I can achieve this is to code it myself by having my own 'redrawNeeded' flag and using this either to short-circuit the draw() implementation or enable/disable the loop That seems a bit untidy to me. Couldn't redraw() just be changed to work from within draw() as well (i.e. trigger the next frame)

I tried out both solutions using a RedrawManager class to manage the state. Here is the version with the loop control:

 private static boolean redrawNeeded = false;
 private static boolean loopRunning = true;

 static void reset() {
   redrawNeeded = false;
 }

 static void redraw(PApplet p) {
   redrawNeeded = true;
   if (!loopRunning) {
     loopRunning = true;
     p.loop();
   }
 }

 static void schedule(PApplet p) {
   if (loopRunning && !redrawNeeded) {
     loopRunning = false;
     p.noLoop();
   }
 }


My draw loop then looks like this:

 void draw() {
   System.out.println("Drawing frame " + frameCount);
   RedrawManager.reset();
   // ... drawing code ...
   RedrawManager.schedule(this);
 }


If I need a redraw any time then I now call RedrawManager.redraw() instead of redraw(). This way my CPU usage is zero when the application isn't changing. The equivalent for a flag to short-circuit the drawing code when it's not needed is simpler, but still uses about 5% CPU in the 'idle' state.

This seems untidy because it needs this extra code to make the best of 'noLoop' mode (unless the visualisation really is static, but then why use Processing?). If redraw() triggered another frame even if it was called within draw() then I could have saved this extra code and a fair amount of head scratching.

I realise that as a software engineer I may be more inclined to look for optimisations than the average user, but software engineers are users too  

I took a look at the code and it should be very easy to change to allow redraw to work from within draw() as well. In the PApplet.handleDraw() method you could just move the line that clears the redraw flag to the top of the enclosing block instead of the end.