Java3D's performance with 2D overlays is notably slow. That being said, there are two camps of thought on how to handle what you want to do:
1. The first is two simulate an HUD overlay by creating some planar geometry (like a Quad), rendering a texture onto it, and doing the appropriate transformations to make sure that the geometry is positioned on the image plate properly.
This is a nice theoretical approach, but practical implementation leads to serious problems. If your camera moves around a lot (like in a virtual environment), the overlay will jitter, which is unacceptable if you want a stationary overlay. There are also clipping issues caused by inherent numerical inaccuracies caused by the various matrix transformations. These clipping problems cause unwanted flickering.
I had a system that used this approach and ended up ditching it because it was such a poor alternative.
2. You can use drawAndFlushImage() in the postRender() method, as you have done. Interestingly enough, I did benchmarks comparing this approach to the approach outlined above, and found the performance difference to be insignificant for my particular system (large M&S environment). The key is understanding that Java3D is smart about some of the 2D functions, and not so smart about others.
Some of the 2D funtions are optimized to render clipped graphics regions onto the image plate. Most, however, just buffer up the graphics into a single large region that fills the image plate. You want to avoid these wasteful functions. Taking care to work with functions that honor small clipping regions will yield the best performance.
I use BufferedImages that are very rarely reallocated, and sized to small region sizes. If I have multiple overlays, I use multiple images. It's far quicker to draw and flush several small images in sequence (especially if there are big spaces in between images) that it is to draw multiple overlays onto a single flushed image.
As a postscript: Remember that the human eye only cares about things up to 60 FPS. Anything over 60 FPS cannot be picked apart by it. So, for animation, pushing things over 60 FPS yields no benefit to the end user.
Hope this helps.
[Message sent by forum member 'bheffner75' (bheffner75)]
To unsubscribe, e-mail: interest-unsubscribe (AT) java3d (DOT) dev.java.net
For additional commands, e-mail: interest-help (AT) java3d (DOT) dev.java.net