Posted by Sven Gothel on Sep 21, 2011; 10:54am
URL: https://forum.jogamp.org/JOGL-2-support-for-Ardor3D-JMonkeyEngine-3-jzy3d-and-NiftyGUI-tp1706747p3355088.html

On Wednesday, September 21, 2011 10:58:39 AM gouessej [via jogamp] wrote:
>
> I tried to use NewtCanvasAWT like GLCanvas but it seems more complicated. Do
> I have to create a NewtCanvasAWT instance on the AWT EDT?
I guess you know this doc:
  http://jogamp.org/jogl/doc/NEWT-Overview.html

- NewtCanvasAWT is an AWT Canvas.
- If you change anything on an AWT tree (Frame, Window, Container, ..)
  which is already made visible .. it shall be done on the AWT EDT.
- It won't hurt to call setVisible(true) of AWT components (Frame, ..)
  on the AWT EDT ..

Besides, our last JOGL/NEWT port of Ardor3D was skipping AWT all the way,
ie only using NEWT.

> How can I force
> the creation of the OpenGL context on the AWT EDT too?

setVisible(true) on GLCanvas or NewtCanvasAWT while it has it's NEWT GLWindow bound.

In the latter case, you always can add/remove a NEWT GLWindow to
NewtCanvasAWT as shown in the demos (see above).

> I now understand why
> another contributor said that Ardor3D FrameHandler API is difficult to use
> with NEWT.

Sorry, I don't know the details anymore.

>
> I can get a valid context by overriding addNotify() in GLCanvas but it does
> not work with NewtCanvasAWT, I had to get the context later in another
> method.

Current Implementation:

Any context whether you use GLCanvas or NewtCanvasAWT or GLWindow
is available after setVisible(true). Since before realizing the native window
we cannot create and bind the context to the native window.

Code snippet from GLWindow:
++
                NativeWindow nw;
                if (window.getWrappedWindow() != null) {
                    nw = NativeWindowFactory.getNativeWindow(window.getWrappedWindow(), window.getGraphicsConfiguration());
                } else {
                    nw = window;
                }
                GLCapabilitiesImmutable glCaps = (GLCapabilitiesImmutable) nw.getGraphicsConfiguration().getNativeGraphicsConfiguration().getChosenCapabilities();
                if(null==factory) {
                    factory = GLDrawableFactory.getFactory(glCaps.getGLProfile());
                }
                if(null==drawable) {
                    drawable = factory.createGLDrawable(nw);
                }
                drawable.setRealized(true);
                context = drawable.createContext(sharedContext);
                context.setContextCreationFlags(additionalCtxCreationFlags);                
++

You can see the following dependency (same in GLCanvas):

  GLContext -> GLDrawable -> NativeWindow -> GLCapabilities

This is the common denominator of creating the resource chain.

- setVisible(true) is kicks off the native Window creation
  which provides the proper chosen GLCapabilities.

- then GLDrawable wraps around the NativeSurface (NativeWindow)
 
- GLDrawable setRealized(true)

Our goal was to allow lazy initialization of the native components,
where we only kick off creation and initialization when required.

This allows users to create instances of a GLCanvas or GLWindow
and add them in their structures etc w/o holding native resources.

I see, it's kind of broken in this path .. just reviewing the code
and sequence of creation/lifecycle here ..

At a first glance, it is possible to create the non initialized
GLDrawable and it's GLContext right away.

A later GLDrawable.setRealized(true) would do the
actual native configuration (updateGraphicsConfiguration()).

And the first GLContext.makeCurrent() actually creates and binds the
native Context to the GLdrawable.

All of this is already implemented, but the creation of the
non initialized pairs (GLDrawable/GLContext) at GLAutoDrawable creation
(GLCanvas, GLWindow).

Even though we do it this way, a user would need to query if the
GLDrawable and GLContext is valid:
  GLDrawable.isRealized()
  GLContext.isCreated()

- This would have no impact if using the GLEventListener.

- This would need users to be carefull if having code like:
     if( drawable.getContext() != null ) { do something with GL }
  IE add the above query on GLContext if it is actually created.


However this would allow users to use the non-initialized objects
being bound to some other data structures.

Would that help you [ and maybe others ] ?

If so, I may try this .. and if it doesn't produce regressions,
we can make it so and publish it this way.

Maybe you can also come online later today,
where we can discuss other details as well .. ?

Cheers, Sven