The same test with sun.java2d.d3d=false and sun.java2d.noddraw=true:
sun_java2d_noddraw_true.txt |
Administrator
|
You should see "NoARBCreateContext" in your logs with the patch, is it the case? If you don't see it, there is something really wrong with the patch.
Julien Gouesse | Personal blog | Website
|
Yes, I can see it. Here is the ouput log with the patch and with 'sun.java2d.d3d=true':
with_patch.txt |
Administrator
|
Does this patch solve your problem, especially with sun.java2d.d3d set to false?
Julien Gouesse | Personal blog | Website
|
No, it doesn't.
|
Administrator
|
Therefore, please create a bug report. Please reproduce your bug with an example using only JOGL if possible, you can use mine:
https://gist.github.com/gouessej/3420e2b6f632efdddf98 Do you get exactly the same stacktrace? Please post it here too.
Julien Gouesse | Personal blog | Website
|
It works perfectly with your example.
Does it mean that the problem is not in JOGL? |
Administrator
|
It's a possible interpretation of your result.
Please can you post the stack trace of the crash with the patch and with sun.java2d.d3d=false? I don't find the same GLException than in your very first post.
Julien Gouesse | Personal blog | Website
|
Yes , indeed, it is not the same exception:
javax.media.j3d.IllegalRenderingStateException: Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1) at javax.media.j3d.JoglPipeline.setupCanvasProperties(JoglPipeline.java:8083) at javax.media.j3d.JoglPipeline.createNewContext(JoglPipeline.java:6440) at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:4602) at javax.media.j3d.Canvas3D.createNewContext(Canvas3D.java:2376) at javax.media.j3d.Renderer.doWork(Renderer.java:881) at javax.media.j3d.J3dThread.run(J3dThread.java:271) DefaultRenderingErrorListener.errorOccurred: CONTEXT_CREATION_ERROR: Renderer: Error creating Canvas3D graphics context graphicsDevice = Win32GraphicsDevice[screen=0] canvas = javax.media.j3d.Canvas3D[canvas0,0,0,240x217] |
Administrator
|
Are you sure that sun.java2d.d3d is set to false in this case?
The exception above means that the only OpenGL context that could be created when working around your driver bug is a context based on Microsoft GDI renderer which is very crappy and not capable enough for Java 3D. I don't see any obvious solution, fill a bug report and someone will have to debug a simple program remotely or use the same graphics card to find another workaround. Sorry to tell you this but: - use my simple example, modify it to create 2 windows instead of one, let me know whether it works - are you forced to use Java 3D? Maybe we can find a more reliable solution and a compatibility API to minimize your effort
Julien Gouesse | Personal blog | Website
|
Hi Julien,
Yes, sun.java2d.d3d=false in the previous exception. Maybe I should have mentioned that earlier that we had similar problems with Java 3D 1.5. OK, I'll create a bug report. Is it find to describe it using Java 3D? I guess I have to create it here: https://jogamp.org/bugzilla/ I've run your simple test with 2 windows and it works perfectly. I'm working on an application that has been using Java 3D for years, though we are thinking of redoing the 3D viewer, but we were hoping to keep on using Java 3D. I'm working on an industrial application which uses a (sort of) orbit behaviour. So, quite similar to OpenFlow 3D viewer but with much smaller data. We only display simple shapes (spheres, cubes, cylinder, ...), nothing fancy. So we need something high level and simple to use for an industrial application. Along the JOGL applications, I believe that JReality would probably be a good option. Otherwise, there is Xith, but the project seem to be dead and JMonkey but it is very much video game orientated. Do you have any suggestion? |
Administrator
|
Hi Adrien
Thank you for this information, it means that it was reproducible with older versions of JOGL and/or the native OpenGL renderer of Java 3D 1.5. I wonder if I could provide a bug fix similar to the one for the bug 1078 but it's impossible to check without some tests on the real hardware. You can create a bug report with Java 3D but please provide the most minimal test case and someone will have to reproduce it with JOGL only later someone as I did the last time I fixed 2 bugs impacting Java 3D. Xith3D is in maintenance mode but I stopped implementing the NEWT part of its backend. It seems to be not very active. I hope that I hurt nobody by writing such things. JReality could be a good option, or maybe Scilab, it depends on your needs. JMonkeyEngine 3 is excellent but it wouldn't allow you to target low end machines as it is entirely based on shaders. MSG is enough only if you need an orbital camera but it's too much limited for a CAD software. LibGDX and JogAmp's Ardor3D Continuation would be a bit harder to use but the design of Java 3D makes it hard to implement numerous features without breaking anything. In my humble opinion, you should copy absolutely all logs and information into your bug report and a contributor (maybe me) will have to spend some time in reproducing and fixing the bugs in JOGL itself. On the long term, I advise to stick to Java 3D if you're really aware of the limitations (no OpenGL ES, no compatibility with forward compatible profiles -> it won't work on OS X if it doesn't provide a backward compatible profile, a debatable design that makes it more vulnerable to race conditions and varied sources of bugs unlike JogAmp's Ardor3D Continuation, no NEWT, no Android support, ...). Java 3D is enough to do nothing fancy, I see what you mean. If there is a real demand for it, I can implement a compatibility API so that the developers can run a subset of Java 3D in JogAmp's Ardor3D Continuation. It's a question of trade-off. My biggest concern is that I fear that you reproduce your bug with other scenegraph APIs anyway. That's why I want to fix it in JOGL.
Julien Gouesse | Personal blog | Website
|
Thanks Julien for all these information, that's very helpful.
I run the JReality demos (applets) on my machine and it worked fine. For the bug report, do I describe it as a crash problem or as a flickering problem or both? |
Administrator
|
There is already another report for the flickering. Please create a bug report only for the crash.
Please confirm that you use Catalyst 15.7.1 and maybe I'll ask you to fill a report against ATI OpenGL driver too: http://www.amd.com/report
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Adrien
JReality doesn't use the very latest version of JOGL. Please ask its maintainers to update it if you plan to use it. It's currently incompatible with JOGL 2.3.1 and later.
Moreover, someone else ported it to JOGL 2 and some parts are poorly implemented, for example the selection of the profile in the JOGL OpenGL 3 viewer.
Julien Gouesse | Personal blog | Website
|
Just to confirm that I'm using Catalyst 15.7.1.
|
Administrator
|
Thanks. As you succeeded in building JOGL, maybe you can remove my patch and run the tests. It would help to reproduce your bug with JOGL without Java3D.
Julien Gouesse | Personal blog | Website
|
Please check my comment on the bug 1201 report.
I've run the tests but I get a series of exceptions saying: java.lang.UnsatisfiedLinkError: (...)\natives\windows-amd64\gluegen-rt.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform |
In reply to this post by Adrien
Lots of ImageJ users have also been reporting these bugs, especially on Windows. Specifically:
Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1) https://github.com/fiji/3D_Viewer/issues/18 createImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.1) https://github.com/fiji/3D_Viewer/issues/17 See e.g. http://forum.imagej.net/t/557 What can I do to help troubleshoot these issues? |
Administrator
|
Hi
They are affected by a JOGL bug, the obsolete Microsoft GDI renderer (supporting only OpenGL 1.1) is picked instead of the real OpenGL driver.
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |