Are GLJPanels hardware accelerated for J2SE5? If not, are they eventually going to be? Swing interoperability would be nice, and i would happily sacrifice a few FPS for it, but my application (involves volume rendering) is taxing enough that it has no prayer of reasonable performance without hardware acceleration. Just wanted to know before i invest the time to convert my GLCanvases to GLJPanels.
Are there substantial issues with removing and readding my GLCanvases/GLJPanels? like do i need to reinitialize my textures for the new context? Anything else of that sort? Basically, i have 4 canvases on the screen, and i would like to resize/rearrange them by changing layoutmanagers. If it’s not possible, then i guess it’s just not possible, but i’m hoping it is?
Once all’s said and done, i’ll try to post some screenshots of my app; it’s very spiff now, thanks predominantly to lots of reading in this forum.
Yes, the rendering to the off-screen surface (a pbuffer) is hardware accelerated in JDK 1.4.2 and JDK 5. The path from that offscreen surface back to the Swing component (using OpenGL frame buffer readback and Java2D BufferedImage drawing) is not hardware accelerated, so it slows down fairly significantly the bigger the window gets. Depending on your application and how long it takes to render each frame you may not be able to notice this. Try it and see. Depending on how you’ve factored your code (if you reference GLAutoDrawable everywhere rather than GLCanvas things should be a lot easier) you may be able to change only a couple of lines of code.
Yes, all of the underlying support should be present in the JOGL library to handle this correctly. We do see occasional issues on some cards with multiple OpenGL contexts and the rapid creation/destruction of said contexts, but if the demos.testContextDestruction.TestContextDestruction JOGL demo works well on your machine then there should probably be more issues. Depending on how you’ve set up sharing of textures and other server-side OpenGL objects between your contexts, you may or may not have to reinitialize the texture objects in the new context. If you keep the contexts independent then yes, every time you get a call to GLEventListener.init() you need to reinitialize your textures.
That would be great. We have a long-standing task to put up a page of projects using JOGL and the more the better.
This is good news. The whole rest of the app that my new stuff has to integrate into is done entirely in swing. So interoperability is quite valuable. It’s a relatively low-framerate app. Cranking full-out on the best hardware i’ve got (6800 GS, for now), the best it usually manages is ~30 fps, and usually less than that, depending on what the user is doing. My direct GLCanvas references are minimal; shouldn’t be too hard to find those and change 'em.
Unfortunately i’ll have to reinitialize i think. I have display lists (for some very repetitive geometry), and a large texture (namely my volume data; roughly 14MB (3x that when we go to color; which i think they’ll want for the next version) that must be shared. Still shouldn’t be too difficult i don’t think.
I said try, as i’m not sure whether or not management will allow me to share those images, but i’ll do my best. Unless of course the people here are all spies for the competition… hmm…
