Re: Newt and reparenting preserving the native window handle
Posted by chrix on Mar 13, 2014; 2:33pm
URL: https://forum.jogamp.org/Newt-and-reparenting-preserving-the-native-window-handle-tp4031873p4031884.html
URL: https://forum.jogamp.org/Newt-and-reparenting-preserving-the-native-window-handle-tp4031873p4031884.html
Hi Sven:
Thanks for the quick replies. My snippet is derived from TestParenting04AWT.java. I've added 4 lines marked with "// <<<<" to compare the window handle before and after reparenting.
Here's the output below. Do you think there's a way to write a snippet where a child window is moved to a different parent while preserving its own native handle on Windows?
Handle before reparenting: 21237418
Handle after reparenting: 21302954
protected void winHopFrame2Frame(final boolean detachFirst) throws InterruptedException, InvocationTargetException {
...
for(state=0; state<3; state++) {
Thread.sleep(durationPerTest);
switch(state) {
case 0:
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
// 1 -> 2
if(detachFirst) {
canvas1.setNEWTChild(null);
canvas2.setNEWTChild(null);
} else {
canvas2.setNEWTChild(null); // free g2 of w2
}
long handle1 = glWindow2.getWindowHandle(); // <<<<<
canvas1.setNEWTChild(glWindow2); // put g2 -> w1. free g1 of w1
canvas2.setNEWTChild(glWindow1); // put g1 -> w2
frame1.invalidate();
frame2.invalidate();
frame1.validate();
frame2.validate();
long handle2 = glWindow2.getWindowHandle(); // <<<<<
System.out.println("Handle before reparenting: "+handle1); // <<<<<
System.out.println("Handle after reparenting: "+handle2); // <<<<<
On Thu, Mar 13, 2014 at 12:16 AM, Sven Gothel [via jogamp] <[hidden email]> wrote:
On 03/12/2014 11:37 PM, chrix [via jogamp] wrote:NEWT's reparenting algorithm only issues a 'destroy' if:
>> 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?
- 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.Yes, the GLState preservation mechanism is orthogonal
>
>
> 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.
but helping to sooth destroy in some cases .. see above.
~Sven
http://forum.jogamp.org/Newt-and-reparenting-preserving-the-native-window-handle-tp4031873p4031879.htmlIf you reply to this email, your message will be added to the discussion below:
signature.asc (894 bytes) | Free forum by Nabble | Edit this page |