Hello,
We have a C app which creates its own OpenGL context, and pass it to JOGL: - we create a Java VM - before starting the drawing in C, when we are sure that we have a valid OpenGL context available, we call a Java method through JNI where we get a GLDrawableFactory, and then call the createExternalContext method - then we can draw our OpenGL content in JOGL This worked ok in JOGL 1.1.1, but not in JOGL 2.0 rc5. However, there is no crash at all, only it seems that the Hava code never goes after the part where it tries to get the factory. Is it a bug in the current rc5 version of JOGL, or us it that we forgot to do something before trying to get the factory (which was not necessary in 1.1.1) ?. FYI, the same version work ok when standalone. Any clues? Hervé |
Administrator
|
Hi
It was working fine with JOGL 2 in April 2011. I didn't try this mechanism later. What do you mean by "FYI, the same version work ok when standalone"? Please could you try the latest auto build instead of the RC5?
Julien Gouesse | Personal blog | Website
|
Ok, I will try it in a few days, and get back here with the results !! Thanks for your answer! Hervé Sent from my iPhone
|
In reply to this post by gouessej
About the fact that it seems to work ok when standalone: when I'm using JOGL for the same app but not using an external context (that is, creating a GLJPanel and using it directly), I have no problem. Which is why I think that my "install" of the JOGL libraries is fine. Of course I still can be wrong.
|
Administrator
|
Please enable all debug logs and maybe use the composable debug pipeline (see DebugGL*). Look at our wiki if you don't see what I mean.
Julien Gouesse | Personal blog | Website
|
Hello, we still have the problem with the latest autobuild, but we were able to track where the problem takes place.
What we do is: GLProfile profile = GLProfile.getDefault(); GLDrawableFactory factory = GLDrawableFactory.getFactory(profile); GLContext context = factory.createExternalGLContext();It works fine if we call this portion of code "standalone," (directly from the Java code while having no external context), except for the last line of course, but it is to be expected. Now if we begin a drawing in C, then execute the method where we have this code in Java through JNI, we have no problem until the last line. The debugger shows that the problem arise in the wglGetCurrentContext method (WGL class) : final long __addr_ = wglProcAddressTable._addressof_wglGetCurrentContext; if (__addr_ == 0) { throw new GLException("Method \"wglGetCurrentContext\" not available"); } return dispatch_wglGetCurrentContext1(__addr_);__addr__ is not null, but dispatch_wglGetCurrentContext1, which is a native method, return null (We are on Windows XP 32 bits). Herve |
Administrator
|
The explanation is here:
http://msdn.microsoft.com/en-us/library/dd374383%28v=vs.85%29.aspx Maybe the context is not current when you try to create an external context. Be aware that the context becomes available later in JOGL 2 than in JOGL 1 but it concerns the Java side.
Julien Gouesse | Personal blog | Website
|
arghh you may be right. When you say "later", does it mean that we have to wait a little in the Java side for the context to be available ? It's true that we called the createExternalGLContext method in Java as soon as possible in the Java side (not because it was really necessary for us though, just because we did not think about it as it worked with JOGL 1.1.1).
However thanks for your advice, but also for your work on this very good API. |
Administrator
|
On 03/29/2012 01:13 AM, herve [via jogamp] wrote:
> > > arghh you may be right. When you say "later", does it mean that we have to > wait a little in the Java side for the context to be available ? It's true > that we called the createExternalGLContext method in Java as soon as > possible in the Java side (not because it was really necessary for us > though, just because we did not think about it as it worked with JOGL > 1.1.1). > > However thanks for your advice, but also for your work on this very good > API. We currently use GLDrawableFactory.createExternalGLContext() in GLJPanel for it's Java2D-OpenGL-Backend and in the SWT unit test 'TestSWTEclipseGLCanvas01GLn'. We currently use GLDrawableFactory.createExternalGLDrawable() only in GLJPanel right now .. Both work use cases work pretty well, having ensured that at the time they are called (fetching the current context and drawable from JOGL), the 'external' entity has set them current. If you like, I would appreciate more unit tests on this. You could simply create the 'external' context w/ JOGL itself and hook it up with with the above mentioned calls and using them. Then we would merge your unit test code and it will be maintained well. The problem w/ your current negative experience is that we have no way to validate your description and reproduce it, since we have no source code. Kind regards, Sven signature.asc (910 bytes) Download Attachment |
Hello, thanks again! Our project is Open Sourced (http://sourceforge.net/projects/j661/), but you would need a much smaller test case as our current use case because as you can expect there is a lot of "noise" unrelated to JOGL in our project ;)
However I'm really OK for providing a test case, at the very least it could help others which might have the same difficulties as we have now (and soon "had", I'm sure). Regards, Herve |
Administrator
|
On 03/29/2012 03:06 AM, herve [via jogamp] wrote:
> > > Hello, thanks again! Our project is Open Sourced ( > http://sourceforge.net/projects/j661/ http://sourceforge.net/projects/j661/ > ), but you would need a much smaller test case as our current use case > because as you can expect there is a lot of "noise" unrelated to JOGL in our > project ;) > > However I'm really OK for providing a test case, at the very least it could > help others which might have the same difficulties as we have now (and soon > "had", I'm sure). > Cheers, Sven > Regards, > > Herve signature.asc (910 bytes) Download Attachment |
Administrator
|
In reply to this post by herve
I see that one more "big" French corporation uses JOGL.
I use createExternalGLContext with GLCanvas in Ardor3D, it works fine. The context of the GLCanvas is not available when creating it, only when adding it into a container whereas in JOGL 1, it was available at its creation. Do you see what I mean?
Julien Gouesse | Personal blog | Website
|
Hello!
Now it works!! As you wrote: "The context of the GLCanvas is not available when creating it, only when adding it into a container whereas in JOGL 1, it was available at its creation". It was exactly our problem. We tried to access the context only once * before * putting something in our GLJPanel. when we add the widget structure before trying to access the context, it works ok. Again thanks, your advices were precious! And yes, Dassault uses JOGL too. I suspect that the J661 project may not be the only one to use it, but at least this one is Open Source ;) Herve P.S.: What we are doing in fact is create a Swing structure inside the GLJPanel, and directly call paint on the top of our structure on a Graphics2D which in fact write in a JOGL Texture. After we end drawing the Swing tree, we render the texture on the OpenGL context in JOGL too. Of course we don't recreate the texture at every draw order. We can't easily use direct OpenGL drawings for that because ARINC 661 widgets are really like Java widgets, and we really need Look and Feel capabilities. |
Administrator
|
Hi
I'm really happy for you. I had forgotten this tiny change and I had got only a NullPointerException until I remembered to take care of this. Maybe you could have a look at JOGL based Java2D implementation, I put the link into the user guide. In my humble opinion, it would allow you to stay away from GLJPanel and to draw all Java-like widgets faster.
Julien Gouesse | Personal blog | Website
|
Thanks, I was not aware that this was possible directly in JOGL (again we switched to 2.0 just 2 weeks ago, and I don't know if it was already possible in 1.1.1). I really think that you are right and that the quality and speed of the rendering would be greatly increased. Sent from my iPhone
|
Administrator
|
That's here:
http://forum.jogamp.org/useful-Java2D-bridge-td3391708.html
Julien Gouesse | Personal blog | Website
|
Very interesting. In fact we tried to use this route, but we were not aware of this bridge, so we used an old totally unsupported GL4Java graphics2D bridge called Agile2D. It "worked" but the result was not functional at all (strictly meaning, it compiled with the last JOGL version after some hacking, and there was something on the screen). Of course we would have need a huge amount of work to have something functional. Much better to use something supported and consistent with the last JOGL version. And if we encounter bugs, it's also better to share them in order to improve it for everybody. Hervé Sent from my iPhone
|
Administrator
|
I know Agile2D a bit too. The idea behind the bridge is almost the same but it is actively maintained. It would be fine to succeed in using it with JFreeChart, we could display nice charts with JOGL. The only limitation of this bridge is that there are still some dependencies with AWT.
Julien Gouesse | Personal blog | Website
|
I looked a little at the source code, and I'm extremely pleased by all the possibilities that are now opening for us. I *might* also be able to help the dev of this bridge a little, because if I'm not a specialist of OpenGL at all, I once helped the Batik project for their WMF converter (it uses a graphics2D pipeline), and I developed a PPT graphics2D pipeline for the j661 project. I saw for example that he did not implement (yet) setPaint for Paint objects which are not instances of Color, for example, and I had a similar need for WMF and PPT, but was able to solve it (through textures as you can imagine). I would also be happy to give back some help for the core JOGL project, but my knowledge of OpenGL is too shallow I fear ;) Hervé Sent from my iPhone
|
Administrator
|
Any help is welcome :)
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |