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?