Posted by Sven Gothel on Mar 13, 2014; 4:16am
URL: https://forum.jogamp.org/Newt-and-reparenting-preserving-the-native-window-handle-tp4031873p4031879.html

On 03/12/2014 11:37 PM, chrix [via jogamp] wrote:
>> Don't make a confusion between the native window handle and the
>> OpenGL
> resources. Ack... So no hope to preserve that native window handle
> when it is reparented, right?

NEWT's reparenting algorithm only issues a 'destroy' if:
  - Becomes CHILD-Window

    - new parent window is not realized yet,
      i.e. parent's window handle is null

    - forceRecreate

    - moving to a new incompatible screen/device

  - Becomes TOP-Level-Window
 
    - forceRecreate

  - reparenting failed

In case 'destroy' is issued, recreation will follow
as soon as the new parent window handle becomes available
or the instant if becoming a top-level window.

+++

In case 'destroy' must be issued, the hint 'REPARENT_HINT_BECOMES_VISIBLE'
will preserve the GLState at destroy.
The preserved GLState will be recovered when recreated.
This mechanism exists to sooth the 'destroy' case.

See: GLStateKeeper, GLEventListenerState

Regularly used in cases:
  - OSX CALayer/Top-Level NEWT Reparenting
  - Android GLState preservation: 'Home Button', 'Rotation' ..

+++

To avoid 'destroy' _and_ the GLState preservation,
the NEWT window shall simply be reparented before
parent's destruction. This is true for 'window hopping'
as well as child->top transition.

See TestParenting04AWT for example ..

I hope this helps a bit ..

+++

I will add the above to the NEWT documentation.

>
>
> On Wed, Mar 12, 2014 at 4:55 PM, gouessej [via jogamp] <[hidden
> email]> wrote:
>
> Hi
>
> Don't make a confusion between the native window handle and the
> OpenGL resources.

Yes, the GLState preservation mechanism is orthogonal
but helping to sooth destroy in some cases .. see above.

~Sven