Canvas vs OpenGL Window

Sorry if this is a little disjointed.  My thought process tends to run over itself.

As I understand it, the createWindow method called on DisplaySystem is actually implemented by the renderer, specifically the LWJGL renderer?  The window it creates is not resizable (I can't drag a corner and shrink/expand it).  I would like a little more flexibility to my window so I dragged some code out of the applet example and created a swing window that I could resize all I wanted with a JMECanvas on it.  It worked fine except for two gotchas.

  1. I keep reading that using a canvas is significantly slower than using a native opengl window.  I'm not quite sure I understand what a native opengl window is, and/or why rendering to a canvas would be slower.  Can someone try and explain that, or point me toward an explanation please?

  2. The framerate on a canvas seems to be locked to the monitors refresh rate no matter what I do.  Rendering in an opengl window is not vsynced, so I know it's off.  After some testing it seems that the jme update rate is directly linked to the canvas repaint rate, and repaints are limited to one per screen refresh.  I can slow down the frame rate in the canvas by increasing the sleep time in my repaint canvas thread.  Am I doing something wrong there or is that an inevitable side effect of rendering to a canvas?

    It seems like I should be able to create a headless display and repaint the canvas from the buffer, or is that what the createCanvas method is actually doing?  Am I completely wrong about where createWindow and createCanvas are being implemented?  If I can see their implementation that would go a long way toward helping me understand.

    Point number one is most important, because the kind of app I have in mind to use jME for (and I would really like to because of all it's features), needs to be able to maximize the window, but not fullscreen.

    And hello to everyone :).  Great to be here.

Heh, nobody knows?  Tough audience out there :).

the canvas method is dependant on the AWT integration and its event thread.

the "non-canvas" uses the lwjgl native display which does not contain an event thread and all sorts of other stuff that might interfere.

as for framerate, try to force vsync off in the drivers.

well, I think the framerate is due to the repaint on the canvas being limited to one per refresh.  rendering and updating are done in a separate thread from the swing/awt thread, so while the repaint might be dependant on the gui thread and currently triggers the updates in the render thread, I think I can probably find a way to unlink the render and update calls from the repaint command, if it's necessary.  I want to know if something like the actual canvas paint is inefficient, and how inefficient it might be.  If I divorce the rendering loop from the canvas repaint, is there any reason to believe the whole app is going to be slower simply because it's using a canvas?