Newt and reparenting preserving the native window handle
Locked
Newt and reparenting preserving the native window handle
 
|
Re: Newt and reparenting preserving the native window handle
Administrator
|
Re: Newt and reparenting preserving the native window handle
|
|
Re: Newt and reparenting preserving the native window handle
Administrator
|
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 |
signature.asc (894 bytes)
Re: Newt and reparenting preserving the native window handle
|
|
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:
|
signature.asc (894 bytes) | Free forum by Nabble | Edit this page |