Problem with GLCanvas in Eclipse RCP application

Hi,

I'm encountering a weird problem on Linux with JDK 7.
I have a GLCanvas in my RCP application (added with SWT_AWT bridge) if I move the window on my second screen (TwinView) and resize it, the GLCanvas is detached and appears in a new window named "JavaEmbeddedFrame" !
No problem with Java 6 and if I replace my GLCanvas by a NewtCanvasAWT, it is not detached.
Why this frame appears ?

thanks,
Best regards

Hi

I used an heavyweight AWT GLCanvas in an Eclipse RCP application for years under GNU Linux too. "JavaEmbeddedFrame" is the default name of the Sun embedded frame used by the brigde to communicate with SWT. Are you satisfied by the behaviour of NewtCanvasAWT? Maybe plan to switch to NewtCanvasSWT or the heavyweight SWT GLCanvas of JOGL 2.0 if it is not the case in order to increase the reliability of your application by avoiding troubles occurring when mixing AWT with SWT.

Do you reproduce your problem with a plain java.awt.Canvas?

On 01/09/2013 12:45 PM, Celine [via jogamp] wrote:
> Hi,
>
> I'm encountering a weird problem on Linux with JDK 7.
> I have a GLCanvas in my RCP application (added with SWT_AWT bridge) if I move

Assuming you mean our AWT GLCanvas ? (Note we have an SWT GLCanvas in JOGL as
well).

> the window on my second screen (TwinView) and resize it, the GLCanvas is
> detached and appears in a new window named "JavaEmbeddedFrame" !
> No problem with Java 6 and if I replace my GLCanvas by a NewtCanvasAWT, it is
> not detached.
> Why this frame appears ?

Fascinating artifacts w/ Java7 lately. On OSX I would expect everything,
but not on Linux.

Would be nice if you could verify whether this bug exists w/o SWT as well,
i.e. a pure AWT application w/ GLCanvas.

You can file a bug report, especially if the above SWT free test
provokes the same bug w/ Java7/X11.
If the latter is not true... it might be some SWT/AWT bridge bug,
which might get solved w/ next SWT release (-> file bug there).

~Sven

>
> thanks,
> Best regards

It seems that with Java 7, the GraphicsConfiguration of the AWT GLCanvas is changed when the window is moved to the second screen and the component peer is recreated.
In a pure AWT application, we can see a "blinking" but with SWT, this change causes the creation of a new window.
I don't know why the NewtCanvasAWT is not detached...

I post a message about this new weird behavior of Java7 on Java forum, they advice me to file a bug at http://bugs.sun.com/ because it needs to be evaluated.

On 01/10/2013 03:11 PM, Celine [via jogamp] wrote:
> It seems that with Java 7, the GraphicsConfiguration of the AWT GLCanvas is
> changed when the window is moved to the second screen and the component peer
> is recreated.
> In a pure AWT application, we can see a "blinking" but with SWT, this change
> causes the creation of a new window.
Thank you!

When it 'blinks', will the GLCanvas stay alive - or is it recreated?
The latter would imply destruction and recreation of the context/drawable
and hence calling destroy(..) and init(..) of all GLEventListeners.

> I don't know why the NewtCanvasAWT is not detached...
NewtCanvasAWT mechanism is different, it attaches to the AWT native peer
Window handle (here a HWND). Hence it seems that the HWND persists (still valid).


>
> I post a message about this new weird behavior of Java7 on Java forum, they
> advice me to file a bug at http://bugs.sun.com/ because it needs to be evaluated.

Could be a bug in SWT as well .. of course.

It's IMHO valid to change the AWT GraphicsConfig of the peer
when you switch screens .. but hey, let them make that decision. :)
However - assuming we use the 'big desktop' setup - all monitors should
be on the same [virtual] screen w/ compatible native configs (HDC ..).

I would also notify the SWT folks, since this AWT
behavioral change really seems to affect them.

Feel free to reference our discussion there.

~Sven

Sven Gothel wrote

When it 'blinks', will the GLCanvas stay alive - or is it recreated?
The latter would imply destruction and recreation of the context/drawable
and hence calling destroy(..) and init(..) of all GLEventListeners.

The GLCanvas is recreated, destroy() and init() are called.

Links to opened bugs:
AWT http://bugs.sun.com/view_bug.do?bug_id=8006421
SWT https://bugs.eclipse.org/bugs/show_bug.cgi?id=397985

Céline, I have just read the both bug reports. In my humble opinion, we will have to live with this change. However, maybe we can find a way to avoid the recreation of the drawable. Are you forced to use SWT_AWT with AWT GLCanvas in your case? What are your constraints?

@Sven Does NEWT do the same thing? (i.e recreation, destruction, initialization after a change of screen / GraphicsConfiguration) I suppose it doesn't as NewtCanvasAWT works.

On 01/22/2013 12:57 PM, gouessej [via jogamp] wrote:
> Céline, I have just read the both bug reports. In my humble opinion, we will
> have to live with this change. However, maybe we can find a way to avoid the
> recreation of the drawable. Are you forced to use SWT_AWT with AWT GLCanvas in
> your case? What are your constraints?

Question here is also what causes the perception of flickering?
Is it
 [a] the delay of the new frame due to GLContext destruction and recreation
 [b] the simple fact that the surface/drawable itself gets recreated

If it's [b] - the behavior might need to be fixed by the culprit (AWT and/or SWT).
If it's [a] - maybe the enhanced/extended GLContext lifecycle (Bug 665) may help.

Bug 665: <https://jogamp.org/bugzilla/show_bug.cgi?id=665>

>
> @Sven Does NEWT do the same thing? (i.e recreation, destruction,
> initialization after a change of screen / GraphicsConfiguration)

The NEWT surface/drawable stays independent from it's attached parent window
[AWT: NewtCanvasAWT - or SWT: NewtCanvasSWT]. A destruction of it's parent simply
triggers a native reparent operation (child -> top).
We have to validate it's re-parenting when the parent's object gets recreated,
but AFAIK this is covered for both (AWT/SWT).
Still - (see above) - this will only mitigate if flickering is caused by [a].

Note: Our SWT GLCanvas uses the same native window parenting as NewtCanvasSWT on X11
      and hence is now a full features JOGL 'widget' on all platforms.

~Sven