Posted by Sven Gothel on Jan 22, 2013; 12:09pm
URL: https://forum.jogamp.org/Problem-with-GLCanvas-in-Eclipse-RCP-application-tp4027754p4027974.html

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