Is it legal to call canvas.display() (where canvas is a GLDrawable) from any thread and at any time if all my GL calls are done inside the display(GLDrawable) callback? In other words if JOGL is in the middle of repainting for some reason outside my control, like handling an OS requested repaint, does it properly block the request to display until it can?
Yes, the proper synchronization is done internally to handle this. Note that currently the implementation can't handle calling the display() method of a drawable while you're inside the display() method of another (or the same one). Unfortunately this restriction isn't documented but fixing it is high on the list of things to do.
Every time I move a window over my frame which contains the GLDrawable I get the following:
I haven't seen a problem like this. Look at any of the jogl-demos demonstrations; they don't seem to exhibit this problem. If you can boil it down to a small test case and it looks like valid code then please file a bug.
If I draw a frame and then the window needs to be redrawn due to a OS level repaint why does the window go white in the occluded areas and never refreshed?
This is true even if I am sitting in a loop in my main thread doing a canvas.display() over and over.
Haven't seen this problem. Many of the demos use either the Animator or setRenderingThread() / setNoAutoRedrawMode() directly to get around multithreaded repainting issues, but unless you're doing something complicated with pbuffers (which some of the demos, like HWShadowmapsSimple and ProceduralTexturePhysics do) then having a repaint request come in every now and then shouldn't matter.