Animator performance issue?

OpenGL Development JOGL Development
#1

Hey, all.

I have some very simple 2D rendering code running, with a few moving images I’m doing with glDrawPixels. I had set rendering on its own timer through my event scheduling package. I then decided to take advantage of the Animator class. Doing nothing but removing the draw from the timer and adding an Animator, my performance falls by almost 60%.

Are there any “common suggestions”, or is it necessary to start pasting code?

#2

The Animator currently consumes 100% of the CPU. If you have anything else going on in your application then the Animator will swamp it. This will be fixed in the JSR-231 APIs and is in progress. You could try using the FPSAnimator from this thread. Something like that will be included in the JSR-231 rewrite of the Animator.

#3

… Wow.

#4

The FPSAnimator class seems to be getting a lot of publicity lately. It was never intended for production use though, so I’m not actually sure how thread safe, stable, … it is. Ken, is it worth putting some effort into refining that class or will the jsr-231 stuff make it obsolete anyway?

#5

(First, thanks for writing it and sorry it took so long to include it and/or rethink the Animator…)

I think the FPSAnimator is probably pretty stable given that it’s received a lot of use. I think it would still be worth putting some more time into it. In the JSR-231 implementation the Animator will not be in the core API but will instead be a utility class. I’m in the process of rewriting it to handle multiple GLDrawables and to not completely hog the CPU. I’ll try to check this in today in the JSR-231 branch of the JOGL tree. I might try an initial import of the FPSAnimator at that point to see if it’s possible to share more code between it and the Animator. At that point could you check out the JSR-231 branch and see what you think?

#6

I had a look at the jsr-231 code and everything seems fine to me (for what that’s worth :slight_smile: ). The only tiny thing I don’t agree with is the inheritance relationship between Animator and FPSAnimator. The only thing they share is the fact that they both hold a list of GLAutoDrawable. FPSAnimator overrides start and stop without calling the super implementation, it does not use the sync method and does not make use of the ignore and print exceptions flags. To me these are bad code smells. Personally I would make an AbstractAnimator that has the drawables list, ignore and print exception flags and a protected method containing the draw code

protected void displayDrawables() {
  Iterator iter = drawableIterator();
  while (iter.hasNext()) {
    GLAutoDrawable drawable = (GLAutoDrawable) iter.next();
    try {
      drawable.display();
    } catch (RuntimeException e) {
      if (ignoreExceptions) {
        if (printExceptions) {
          e.printStackTrace();
        }
      } else {
        throw(e);
      }
    }
  }
}

Or if you’re a delegation fan do the same thing with an AnimatorSupport class to which Animator and FPSAnimator delegate.
I don’t know what the general policy is on output, but it might also be interesting to use the logging api instead of Exception#printStackTrace().

#7

Agreed and thanks for your suggestions. It turned out that this was necessary anyway in order to improve the efficiency of drawing multiple GLJPanels, which occurs in the JRefract demo. Animator.sync() has been deleted. Animator is still the base class and the primary means of subclassing is overriding start() and stop() as FPSAnimator does. Please post if you have more comments or suggestions.

#8

Hi. How about an addition of a query function–say, isAnimating(). I have instances where calling animator.start() the second time crashes the program. - AK77

#9

Can’t you just create new thread to run the animator and set it piority to lowest?

#10

Thanks for the suggestion; this has been added to the JSR-231 branch of the JOGL tree.