Animator question.

Please could somebody explain to me the difference(if there is one) between the following techniques.

  1. starting a Thread and in the run() method repeatedly calling glcanvas.display()

and

  1. Using an Animator class, which would repeatedly call glcanvas.display() once it is started?

Almost no difference, I actually just posted my code for a CustomAnimator that does mostly just call display.

Event thread getting choked

If you just setup a thread that calls display it will work, but it takes a little extra care to exit gracefully.

Don’t forget to call setRenderingThread otherwise GLContext will call wglMakeCurrent every frame rather than doing it just once. It will increase performance.

I am not happy with the frame rate which my thread is painting (and the display also appears a little jumpy), so I tried setRenderingThread() which did not make any difference. Each call to display has to make approximately 3000 glDrawPixels calls where the images to be drawn are rectangular 8x16 pixel 32 bit png (which are already loaded into memory so no time is lost there). I am getting roughly 11 paints per second. If I could get this to a smooth 30 I’d be a happy lady.

As a test, I tried

System.out.println(canvas.getRenderingThread());

and this gave me a null pointer exception (don’t know if this is relevant or not but it left me with the impression that my preceeding SetRenderingThread statement had failed for some reason).

Interesting. You might want to use textured quads rather than drawpixels. I think most drivers are optimized for the former rather than the later. I assume you are passing your rendering tread as the parameter for setRenderingThread. If that function fails it should be throwing an exception so that is strange.

[quote]If you just setup a thread that calls display it will work, but it takes a little extra care to exit gracefully.
[/quote]
Are there any downsides other than the graceful exit? What all is done to achieve the graceful exit?

Not really. The Animator class is reasonably well written and serves for most simple applications. If you get to large apps and start building your own scene graph structures, then the extra level of fine control over the rendering thread and application code synchronisation will mean that having a custom code path will be more useful to you. However, before you wander off down that path, I would recommend that you investigate one of the scene graph APIs that are already being developed over the top of JOGL, such as Xith3D or Aviatrix3D. This will save you a lot of headaches later on.