Login  Register

Re: Java 3D crash or flickering

Posted by ctrueden on May 31, 2016; 9:02pm
URL: https://forum.jogamp.org/Java-3D-crash-or-flickering-tp4035074p4036767.html

philjord wrote
This is definitely an issue for core Jogl, however if Julien agrees I could open a new enhancement (or bug?) in the Java3D space for a patch of some sort to the JoglPipeline that doesn't use the getMaxFixedFunc(true) but rather demands a certain Profile based on a -Dj3d property that could be optionally set by the invoker of Java3D.
I do not know much about how JOGL works, but naively that sounds like a good idea to me, and seems orthogonal to an upstream bugfix. That is: wouldn't it be nice to be able to hardcode a profile, for debugging purposes, even if this specific bug gets fixed?

philjord wrote
If we can get a large number of different test log files we could try to establish what graphics cards/OS combinations cause it and possibly allow a request for a certain driver.

Of course I'd need your help in testing the patch in some manner to ensure it worked so we might have to carefully attempt to deploy it to some users who are suffering before making an official release.
Definitely. There are lots of ImageJ users who I'm sure would be happy to test such things. Our primary modes of community discussion are the ImageJ Forum (http://forum.imagej.net/) and GitHub Issues (in this case: https://github.com/fiji/3D_Viewer/issues).

philjord wrote
What is ImageJ status versus Java3D version? Is it currently 1.6-pre12? If so the newest version of JAva3D requires the package names to be updated, is that sort of thing possible?
Actually, I forked the project: https://github.com/scijava/java3d-core

I did that before Java 3D adopted new package names upstream -- and actually, I am the one who contributed those package rename patches upstream, for the reasons discussed here:

http://forum.jogamp.org/Java-3D-Use-Maven-to-build-and-publish-Maven-artifacts-td4035555.html

So for the moment, all ImageJ + Fiji components use the package prefix org.scijava.java3d.

As an aside, I must say the current state of Java 3D upstream makes me nervous:

- We still have https://github.com/hharrison/java3d-core et. al.
- Then we have https://github.com/gouessej/java3d-core which purports to be a fork of the hharrison version but is supposedly the official repo now.
- Why isn't the official repo https://github.com/jogamp/java3d-core ?
- I feel completely in the dark about the plan for Java 3D 1.7.

So for ImageJ, for the moment, sticking with the SciJava fork is much simpler. We'll be happy to switch to the official Java 3D 1.7 after it is released.

philjord wrote
Having said that if Jogl core gets the issue fixed then a very temporary patch just for ImageJ might last until the next Jogl is release?
Sure, it seems like that would be very helpful.

philjord wrote
ctrueden, what are your thoughts on ImageJ's ability to have code altered or a new java3d jar distributed and a property set some how, to deal with this issue?
Cutting new releases of the SciJava fork is easy anytime. Similarly, pushing patches to users for testing via the ImageJ distribution mechanism (update sites) is also straightforward.

philjord wrote
Also what sort of scale is the problem, as a percentage of users?
Hard to say. I do not know what percentage of users use ImageJ's 3D Viewer, which is the affected component here. And I do not know what percentage of 3D Viewer users are impacted by the JOGL bug. But given the number of bug reports (somewhere between 5 and 15 so far?), I expect it is affecting a non-trivial percentage of people.

philjord wrote
Can you users run a bat file and send the output to you or me, or are they not quite that sophisticated?
Some of the bug reporters are definitely willing and able to do that, yeah.

philjord wrote
Or could they follow these instructions? Please run this program and post the result here:
http://jogamp.org/deployment/jogamp-current/jogl-application-version.jnlp

You may have to add jogamp.org to the exception list to run it:
https://www.java.com/en/download/faq/exception_sitelist.xml

Note that all of the above basically assumes that some sort of specific instruction can be used to work around the software renderer issue.
Thanks, I'll pass it along via our issue tracker!