For a long time now, we've avoided using the benefits first offered by Java 6 in Ardor3D. For the most part, they were small things... a useful method here and there. We stayed with version 5 partially because 6 was still fairly new and there were certain platforms (Mac, I'm looking at you) where it was a challenge to get a working copy.
Java 6 has now been out on Windows and Linux for over three years and has been available on OSX in 64 bit form for about two. 32 bit Mac owners were officially left out in the cold (unless they went out and installed soylatte) until the recent release of OSX "Snow Leopard" (confirmed). Stats show version 6 as the default on about two thirds of machines, with version 5 coming in at about 14%.
A recent programming task had us looking longingly at yet another Java 6 feature (this time, scripting support) and thinking maybe it's finally time Ardor3D moved its min spec to the much more performant Java 6. After looking around and gathering the above numbers, I think it is.
Agree? Have a different take? Give a shout here or on the forums and tell us what you think.
Nexus One
Yes I know the time has well passed, but I've had these unbox photos sitting around for a while waiting to go up... If you only look at one, see the last one. ;)
Jogl and Mac
I do most of my Ardor3D programming (and before that, jME) on a Mac under OSX and have long wondered why jogl performed so much slower than lwjgl there. In troubleshooting, the only difference I noticed was that under jogl, I was taxing my cpu a lot less. That, and if I took the ratio of difference in CPU usage and multiplied it against the jogl frame rate, I would get something close to the lwjgl framerate. So perhaps jogl was "running" as fast, however it was just being held back by something. But what? More troubleshooting and a few messages back and forth with Ken Russell did not uncover the root of the slowdown, so I decided to be content with letting it be for the last couple of years.
A recent edit to JoglCanvas in Ardor3D though finally appears to have uncovered the reason for my OSX jogl slowdown. Unlike lwjgl which uses a native window to host the GL surface, jogl uses an AWT canvas. We've embedded that in an AWT Frame. lwjgl's window is not resizeable, but with jogl you could leave the Frame resizeable and with some added listeners, you could resize the camera and make things look "right" as the window is altered.
This evidently comes at a price in OSX though, and here's where I am guessing at the causes. The jogl GL surface panel in our AWT Frame went all the way to the edge of the border on the window and therefore, OSX draws it's resize handle partially over the 3D content like so:
Anytime other windows or growl messages or whatnot appear over my GL windows (be they lwjgl or jogl based) I see a similar drop in performance... like perhaps OSX is having to synchronize the GL contexts so it can do compositing for those fancy dropshadow effects. Knowing that... might the resize handle also be done by compositing and cause a similar slowdown? The JoglCanvas was recently made non-resizeable as the default (to homogenize our normal canvas behavior) and lo and behold, my jogl frame rates are now very close to their lwjgl counterparts. Mystery solved?
A recent edit to JoglCanvas in Ardor3D though finally appears to have uncovered the reason for my OSX jogl slowdown. Unlike lwjgl which uses a native window to host the GL surface, jogl uses an AWT canvas. We've embedded that in an AWT Frame. lwjgl's window is not resizeable, but with jogl you could leave the Frame resizeable and with some added listeners, you could resize the camera and make things look "right" as the window is altered.
This evidently comes at a price in OSX though, and here's where I am guessing at the causes. The jogl GL surface panel in our AWT Frame went all the way to the edge of the border on the window and therefore, OSX draws it's resize handle partially over the 3D content like so:
Anytime other windows or growl messages or whatnot appear over my GL windows (be they lwjgl or jogl based) I see a similar drop in performance... like perhaps OSX is having to synchronize the GL contexts so it can do compositing for those fancy dropshadow effects. Knowing that... might the resize handle also be done by compositing and cause a similar slowdown? The JoglCanvas was recently made non-resizeable as the default (to homogenize our normal canvas behavior) and lo and behold, my jogl frame rates are now very close to their lwjgl counterparts. Mystery solved?
Subscribe to:
Posts (Atom)