Resize behavior of GLCanvas on OS X (10.7 and 10..8)

When a frame containing a GLCanvas is resized by the app user, the image currently displayed is distorted to fit the new size while the window is resizing. Once the resize is complete the display method is called so code can adjust the viewport and view for the new size, correcting the distortion. Apparently, something is stretching and displaying the current contents of the frame buffer before allowing the app to redraw. This happens only on OS X using JOGL 2 and Java 7. On Windows it works fine. Has anyone run into this or know a workaround?

Please use the latest build. It is a known problem. Some people already reported it, Sven pointed out several bug reports in Java itself, maybe we can find a workaround.

On 01/05/2013 02:49 AM, tag [via jogamp] wrote:
> When a frame containing a GLCanvas is resized by the app user, the image
> currently displayed is distorted to fit the new size while the window is
> resizing. Once the resize is complete the display method is called so code can
> adjust the viewport and view for the new size, correcting the distortion.
> Apparently, something is stretching and displaying the current contents of the
> frame buffer before allowing the app to redraw. This happens only on OS X
> using JOGL 2 and Java 7.

Well, I have seen had similar behavior, but a bit more relaxed.

What you describe is the 'scale when resize' "feature",
which removes a burden from the underlying application
to resize the drawable for each step.

In NEWT (AFAIK) we have set this to 'true resize' for OSX
and works well.

For AWT we cannot do anything, since the AWT does the window/surface
initialization .. as far as I understand.

Iff the intermediate resize events are _not_ delivered via AWT
there is nothing we can do about it!

You may create a 'bug' report and tag it as an 'enhancement'.
Even if it is not 'our' failure here, you may use it as reference
to your followup bug report w/ either OpenJDK and/or Oracle.
I don't actually know who is in charge here.

> On Windows
and Linux etc etc .. :)
> it works fine.

> Has anyone run into this or
> know a workaround?

Use NEWT, i.e. NewtCanvasAWT .. if you like.

~Sven

On 01/05/2013 02:27 PM, Sven Gothel wrote:
> On 01/05/2013 02:49 AM, tag [via jogamp] wrote:
>
>> Has anyone run into this or
>> know a workaround?
>
> Use NEWT, i.e. NewtCanvasAWT .. if you like.

Hi Tom,

on a second thought, considering your intended use I assume,
I recommend to use NEWT as your GLAutoDrawable (i.e. GLWindow).

This can be used w/ AWT via NewtCanvasAWT, if AWT/Swing is required
and an opaque heavyweight component is allowed.
The benefit of using NEWT would be to allow your application
on mobile devices as well if you can implement your renderer
using GL2ES2.
Of course, you can always query the actual GL context
and branch to a 'better' renderer implementation, i.e. using GL3 core.

But .. I guess I already mention this a while ago :)

>
> ~Sven
>
>