JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

classic Classic list List threaded Threaded
215 messages Options
12345 ... 11
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Monday, September 12, 2011 10:59:26 PM gouessej [via jogamp] wrote:

>
> Hi!
>
> I'm very proud to announce that I have finally succeeded in fixing the
> blocking bug which prevented me to use Ardor3D with JOGL 2:
>
>     @Override
>     public void addNotify() {
>         super.addNotify();
>         _canvasRenderer.setContext(getContext());
>     }
>
>
> [b]Ardor3D examples work perfectly with JOGL 2.0[/b]  :D
>
> http://forum.jogamp.org/file/n3330841/ardor3dJogl2RendererFirstSuccess.png 
>

Kudos !

Looking forward to your SCM repository and efforts to merge it back to Ardor.
Also looking forward to see NEWT working w/ Ardor,
but I guess this is a simple task.

Please share this information w/ us, very much appreciated.

>
> I have just rewritten my straightforward port in about 3 hours, I will use
> it with TUER very soon, probably in some days.

Awesome.

Cheers, Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
Actually, I should have been able to fix it earlier. You changed the way of handling the context to fix some bugs, I remember that something has been modified in addNotify() and removeNotify() in the GLCanvas.

The next step are these furthers:
- modify the pom.xml file to provide a proper support of Maven (if someone has already succeeded in using Maven and JogAmp, please let me know)
- provide an headless JOGL Ardor3D canvas so that developers using JOGL benefit of the same features than developers who chose our competitor
- provide both a pure NEWT window and a NEWT AWT Ardor3D canvas

The source code will be committed on my SVN repository in a few days.

Some constants still use suffixes which should have disappeared (_ARB, _EXT), is there a reason for that?

I have to clarify some aspects with Renanse.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Tuesday, September 13, 2011 10:37:34 AM gouessej [via jogamp] wrote:
>
> Actually, I should have been able to fix it earlier. You changed the way of
> handling the context to fix some bugs, I remember that something has been
> modified in addNotify() and removeNotify() in the GLCanvas.

A while ago, yes. AFAIK I did this on your bug report about the GLCanvas lifecycle,
ie. remove/add the GLCanvas to Frames.

>
> The next step are these furthers:
> - modify the pom.xml file to provide a proper support of Maven (if someone
> has already succeeded in using Maven and JogAmp, please let me know)

Sadly no. However, some people did try or started this task
but I never got a 'success' message and the pull request in this regard.

> - provide an headless JOGL Ardor3D canvas so that developers using JOGL
> benefit of the same features than developers who chose our competitor
headless -> no AWT - this implies NEWT ?

> - provide both a pure NEWT window and a NEWT AWT Ardor3D canvas
great. so the android Ardor3d will be possible.

>
> The source code will be committed on my SVN repository in a few days.
Can I vote for git ? :)
Don't the Ardor3D guys use git as well these days ? Sorry, don't know.
Well .. sure, there is always the svn-git bridge.

>
> Some constants still use suffixes which should have disappeared (_ARB,
> _EXT), is there a reason for that?
Removing the extension suffix is done for subsumed extensions into GL profiles/versions.
So the not yet subsumed extensions are still visible in their namespace.
I know, especially the old shader program ARB extension seem to be duplicated,
however, the extension is not 100% compatible w/ the OpenGL 2.0 GLSL,
hence the duplication of that one (if you refer to tha).

>
> I have to clarify some aspects with Renanse.

Sweet.

Can you re-introduce me to him so the three of us can have
a discussion about NEWT, mobile and future JOGL support ?
I really would appreciate that .. if there is an interest.

Thank you Julien for your great work.

Cheers, Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
I had not thought that it would change the way of getting the context, sorry, it was my fault.

Jzy3d uses Maven with JOGL 2, I will call or send an email to Martin to get some information about that.

Is NEWT mandatory to make an headless canvas?

Ardor3D already supports Android but with a separate engine. However, it would be interesting to be able to support other platforms, some ARM-based tablets.

Ardor3D uses SVN. I planned to use SVN too but if you prefer GIT, I will try to put the source code on Github.

I spoke about you to Renanse, he just answered me:
"Personally, I support the idea, but don't have any time to help in this endeavor, so you will need to be the champion of it." + "Congrats"

I'm not a champion but I do my best.

You're welcome. I still have a lot of work and I know only a very little NEWT, I will have a look at the test cases.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Tuesday, September 13, 2011 11:29:52 PM gouessej [via jogamp] wrote:
>
> I had not thought that it would change the way of getting the context, sorry,
> it was my fault.
np, thx to your report, so we fixed it :)

>
> Jzy3d uses Maven with JOGL 2, I will call or send an email to Martin to get
> some information about that.
nice

>
> Is NEWT mandatory to make an headless canvas?
IMHO headless == no AWT, in this case, NEWT is our only availble
native windowing toolkit.
Or we are confusing 'headless' here .. getting headless :)

>
> Ardor3D already supports Android but with a separate engine.
Sure, probably with Androids own ES1 .. API.

But for us, we would love to have Ardor3D + Android + JOGL (implies NEWT) running.
Rational:
 - JOGL's Android port exist so you can reuse your JOGL based code on Android
   without rewriting the world -> shortens development cycles.

 - Using the Ardor3D API is an option, and maybe done in parallel of direct JOGL usage,
   hence the combination Android + JOGL + Ardor3D is essential.
   However - after we have Ardor3D + JOGL/NEWT available, it shall be implicit.

> However, it
> would be interesting to be able to support other platforms, some ARM-based
> tablets.

See above .. and sure, Linux/X11 based ARM boards will be supported implicit by
our JOGL/Linux/ARM build, which will surface soon w/ Android on jenkins.

>
> Ardor3D uses SVN. I planned to use SVN too but if you prefer GIT, I will try
> to put the source code on Github.
Oh .. sorry, I didn' know that he is still using SVN :)
OFC .. in such case, pls stick w/ it .. so he is able to pull your changes.

>
> I spoke about you to Renanse, he just answered me:
> "Personally, I support the idea, but don't have any time to help in this
> endeavor, so you will need to be the champion of it." + "Congrats"
>
> I'm not a champion but I do my best.

:)

You are the man!

Sure, time is always limited. So lets see how your port goes
and how much of a success we will have with Ardor3D on all the platforms
using AWT / NEWT.

>
> You're welcome. I still have a lot of work and I know only a very little
> NEWT, I will have a look at the test cases.

Understood. I will pitch in after Android is done, refreshing my Ardor3D knowledge.

Great stuff.

So lets keep the ball rolling.

I assume your SVN branch will be available soon ?

Laters & Kudos

~Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
Ardor3D uses a separate engine in order to use a more simple version (compared to the desktop one) with specific optimizations for Android. I agree with you but I know that Android does not use a real JVM, I would feel better with Java SE For Embedded but without scary licensing.

I don't know when the implementation of the NEWT Ardor3D canvas will be ready but I will try to commit my source code Friday evening in the worst case.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
In reply to this post by Sven Gothel
Hi!

As far as I know, it is possible to mix AWT and NEWT, am I wrong?

Does NEWT have such a limitation?
http://www.java-gaming.org/index.php/topic,24650.msg208525.html#msg208525
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Friday, September 16, 2011 01:15:43 PM gouessej [via jogamp] wrote:
>
> Hi!
>
> As far as I know, it is possible to mix AWT and NEWT, am I wrong?
>

OFC, thats the mentioned NewtCanvasAWT .. on my blog

  http://jausoft.com/blog/2010/11/28/newt-threading-overview/

In a bit (rc is building) .. v2.0-rc3 is out
and you can see NEWT/AWT Applets in action.

Oh .. the rc2 version showed this combination as well.
(Will send an update about rc3 when it's done in a separate thread.)

We have several ways to combine NEWT/AWT, via the native parenting
of a NEWT window to an AWT component (NewtCanvasAWT).
We also have event adapter translating AWT events to NEWT
(as we have one for Android to NEWT).
Plus we have one AWT implementation of NEWT :)



~Sven

> Does NEWT have such a limitation?
> http://www.java-gaming.org/index.php/topic,24650.msg208525.html#msg208525
> http://www.java-gaming.org/index.php/topic,24650.msg208525.html#msg208525 
>
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
This post was updated on .
Hi


The JOGL renderer of Ardor3D based on JOGL 2 is ready:
http://gouessej.wordpress.com/2011/09/18/le-moteur-3d-ardor3d-fonctionne-desormais-avec-jogl-2-the-3d-engine-ardor3d-now-works-with-jogl-2/

Edit.: I have just added some complementary explanations on my blog as I feared that people do not understand how to replace the existing renderer by mine.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
I have implemented a NEWT window for Ardor3D but I have not yet tested it as I need to implement some wrappers for key and mouse inputs.

I see I can neither change the mouse cursor nor set a grabbed state. It will be problematic for my game, I will have to implement it in NEWT.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Monday, September 19, 2011 09:13:39 PM gouessej [via jogamp] wrote:
>
> I have implemented a NEWT window for Ardor3D but I have not yet tested it as
> I need to implement some wrappers for key and mouse inputs.

Right now we have 2 event translators implemented:
  AWT -> NEWT
    http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/jogamp/newt/awt/event/AWTNewtEventFactory.java;hb=HEAD
       
  Android -> NEWT
    http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/jogamp/newt/driver/android/event/AndroidNewtEventFactory.java;hb=HEAD

maybe it would be cool to have NEWT -> AWT
  com.jogamp.newt.awt.event.NewtAWTEventFactory ?

somehow I am reluctant to write something that would enable AWT to use NEWT,
however, real world use cases show it would be convenient.
Do you like to do implement them ?

>
> I see I can neither change the mouse cursor nor set a grabbed state. It will
> be problematic for my game, I will have to implement it in NEWT.

Yup, the 2 last outstanding feature requests to NEWT.
They will come, sure.

- turn mouse cursor on/off (if not supporting change the cursor image)
- mouse cursor doesn't leave window (grabbed ?) on/off

sounds great, will do for rc4.

~Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
This post was updated on .
Hi

I implemented one of those wrappers (JoglNewtMouseWrapper) before falling asleep, I used the previous one (AwtMouseWrapper) as an example, it seems to be the right way to do it :) The one I implemented wraps NEWT events directly in Ardor3D events in order to allow the use of this window without AWT on Android for example.

I'm going to implement the class JoglNewtAwtCanvas which uses NewtCanvasAWT with existing wrappers (AwtMouseWrapper, AwtKeyboardWrapper, ...). If I do so, I won't need (yet) NewtAWTEventFactory. If I need it, I will implement it.

If you think it is a bad idea, let me know. As the source code is on Sourceforge, you can have a look at it.

I can at least find the native calls to change the mouse cursor and to move the mouse pointer on several platforms, would it be useful for you?

In Ardor3D, it is possible to change the icon of the window. Would such an option be difficult to implement in NEWT?

Thanks for your help. Best regards.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Tuesday, September 20, 2011 11:16:53 AM gouessej [via jogamp] wrote:

>
> Hi
>
> I implemented one of those wrappers (JoglNewtMouseWrapper) before falling
> asleep, I used the previous one (AwtMouseWrapper) as an example, it seems to
> be the right way to do it :) The one I implemented wraps NEWT events
> directly in Ardor3D events in order to allow the use of this window without
> AWT on Android for example.
>
> I'm going to implement the class JoglNewtAwtCanvas which uses NewtCanvasAWT
> with existing wrappers (AwtMouseWrapper, AwtKeyboardWrapper, ...). If I do
> so, I won't need (yet) NewtAWTEventFactory. If I need it, I will implement
> it.
>
> If you think it is a bad idea, let me know. As the source code is on
> Sourceforge, you can have a look at it.

Great stuff. You are right, lets do this step by step.
When you have it 'merge/review ready' please open a new thread about it here.
(This thread is already pretty huge :)

Then we see how to best migrate it to NEWT. Cool.

>
> I can at least find the native calls to change the mouse cursor and to move
> the mouse pointer on several platforms, would it be useful for you?

Of course.
I will add it to the Window .. and hopefully thats about it.
Sure, the 'grab' feature may need some special handling, ie shutdown callback.
At least we have to ensure that it won't mess with the whole desktop :)
As above - pls send these code snippets in a new thread in this forum.
Thank you.

>
> In Ardor3D, it is possible to change the icon of the window. Would such an
> option be difficult to implement in NEWT?
If we have your above native functions .. and know how they work .. no :)
Just replace difficult with time consuming .. I guess.
Ie we would need to find a common bitmap format I guess.
Lets do this after we were able to turn it on/of + grab-feature.

>
> Thanks for your help.
Thank you.

> Best regards.

Cheers, Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
For Linux:
XGrabPointer
XUngrabPointer
XDefineCursor
XWarpPointer

For Windows:
ClipCursor
?
SetCursor, CreateCursor, ShowCursor
SetMousePos (or SetCursorPos?)

For Mac:
XtGrabPointer
XtUngrabPointer
?
?

It would be fine to have the same behavior than our "competitor":
http://lwjgl.org/forum/index.php?topic=3236.0
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
In reply to this post by Sven Gothel
The application crashes when I call NewtCanvasAWT.requestWindow() :

Stack: [0x8f7ff000,0x8f850000],  sp=0x8f84ebe0,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libX11.so.6+0x1f454]  XGetInputFocus+0x14
C  [libnewt.so+0x5945]  Java_jogamp_newt_driver_x11_X11Window_requestFocus0+0x4c
j  jogamp.newt.driver.x11.X11Window.requestFocus0(JJZ)V+0
j  jogamp.newt.driver.x11.X11Window.requestFocusImpl(Z)V+10
j  jogamp.newt.WindowImpl$RequestFocusAction.run()V+89
j  com.jogamp.common.util.RunnableTask.run()V+93
j  jogamp.newt.DefaultEDTUtil$EventDispatchThread.run()V+155
v  ~StubRoutines::call_stub
V  [libjvm.so+0x242876]  AsyncGetCallTrace+0x80736

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.newt.driver.x11.X11Window.requestFocus0(JJZ)V+0
j  jogamp.newt.driver.x11.X11Window.requestFocusImpl(Z)V+10
j  jogamp.newt.WindowImpl$RequestFocusAction.run()V+89
j  com.jogamp.common.util.RunnableTask.run()V+93
j  jogamp.newt.DefaultEDTUtil$EventDispatchThread.run()V+155
v  ~StubRoutines::call_stub
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
In reply to this post by Sven Gothel
I get this when resizing JoglNewtAwtCanvas:
Exception in thread "main" javax.media.opengl.GLException: Error: Attempt to make context current on thread Thread[main,5,main] which is already current on thread Thread[main-Display-X11_:0-1-EDT-1,5,main]
        at jogamp.opengl.GLContextImpl.lockConsiderFailFast(GLContextImpl.java:219)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:385)
        at com.ardor3d.framework.jogl.JoglCanvasRenderer.makeCurrentContext(JoglCanvasRenderer.java:89)
        at com.ardor3d.framework.jogl.JoglCanvasRenderer.draw(JoglCanvasRenderer.java:188)
        at com.ardor3d.framework.jogl.JoglNewtAwtCanvas.draw(JoglNewtAwtCanvas.java:61)
        at com.ardor3d.framework.FrameHandler.updateFrame(FrameHandler.java:90)
        at com.ardor3d.example.canvas.JoglNewtAwtExample.main(JoglNewtAwtExample.java:133)

Maybe I should run some operations on the EDT.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
On Tuesday, September 20, 2011 08:20:33 PM gouessej [via jogamp] wrote:

>
> I get this when resizing JoglNewtAwtCanvas:
> Exception in thread "main" javax.media.opengl.GLException: Error: Attempt to
> make context current on thread Thread[main,5,main] which is already current
> on thread Thread[main-Display-X11_:0-1-EDT-1,5,main]
> at jogamp.opengl.GLContextImpl.lockConsiderFailFast(GLContextImpl.java:219)
> at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:385)
> at
> com.ardor3d.framework.jogl.JoglCanvasRenderer.makeCurrentContext(JoglCanvasRenderer.java:89)
> at
> com.ardor3d.framework.jogl.JoglCanvasRenderer.draw(JoglCanvasRenderer.java:188)
> at
> com.ardor3d.framework.jogl.JoglNewtAwtCanvas.draw(JoglNewtAwtCanvas.java:61)
> at com.ardor3d.framework.FrameHandler.updateFrame(FrameHandler.java:90)
> at
> com.ardor3d.example.canvas.JoglNewtAwtExample.main(JoglNewtAwtExample.java:133)
>
> Maybe I should run some operations on the EDT.

Run AWT modifications on the AWT-EDT, yes, this is a requirement
of AWT/Swing. This is true if you modify NewtCanvasAWT, which is an
AWT component holding a NEWT Window.

You don't need to take care if you modify a NEWT Window,
since the methods already spin of the modify action to it's NEWT EDT.

~Sven
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

gouessej
Administrator
I tried to use NewtCanvasAWT like GLCanvas but it seems more complicated. Do I have to create a NewtCanvasAWT instance on the AWT EDT? How can I force the creation of the OpenGL context on the AWT EDT too? I now understand why another contributor said that Ardor3D FrameHandler API is difficult to use with NEWT.

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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Sven Gothel
Administrator
In reply to this post by gouessej
On Wednesday, September 21, 2011 12:54:15 PM Sven Gothel wrote:

>
> 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.

The problem here would be the dependencies to the NativeSurface/NativeWindow
configuration while creating the proper GLDrawable via the GLDrawableFactory.

Actually this dependency makes it hard for the GLCanvas only,
where we need to fetch the AWTGraphicsConfiguration,
which is only valid when visible (addNotify()).

We might be able to defer the native configuration setting at
GLDrawable.setRealize() while passing the new native configuration,
but this would imply a view side effects I am afraid and will consume time to do properly.

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

Also, the GLAutoDrawable spec currently claims that GLContext is not
persistent, ie don' rely on it's identity.
This actually hinders one from storing GLAutoDrawable GLContext's
but would need to query it before using.

I see, it's quite complicated, sorry about that.

Maybe best would be to reference the GLAutoDrawable (GLCanvas, GLWindow) itself,
and always query the GLContext there if needed .. and only act if valid.

Can you send a link to the source code online, so I can see the problems in detail ?

~Sven
12345 ... 11