Posted by gouessej on Aug 22, 2016; 7:57pm
URL: https://forum.jogamp.org/Java-3D-initialization-is-super-slow-tp4037070p4037082.html

ThinWhiteDuke wrote

Ok, thanks! With your link I was able to find a workaround to this problem by extracting native library dll's to java library path and using -Djogamp.gluegen.UseTempJarCache=false argument.

You're welcome. I understand that this bug is annoying but keep in mind that the automated native deployment doesn't work on restricted machines on which it isn't allowed to uncompress files in the usual locations. In other words, this mechanism is very handy but you can totally stop using it with a very few efforts in your deployment methods. Personally, I bundle my own game with an OpenJDK JRE, I totally control how it gets installed, everything is currently automated with Ant. If you use a single "fat" JAR, this workaround prevents you from going on providing it alone with no other files but if you use a good packager like the build-in packager in Netbeans (based on Inno Setup and Wix), javapackager, or JNDT (the next version will probably use NSIS), you can just put the native libraries into your bundle and use my workaround. You can even deploy a bundle containing an exploded JAR, i.e your bundle contains the files that are usually in the JAR(s). If your own "fat" JAR is already merged with jogamp-far.jar and if your tool preserves the location of the native libraries, deploying an exploded JAR with my workaround is not that hard for you and convenient for the end users who still have a single file to download.

ThinWhiteDuke wrote

Any guesses when a fixed jogamp package would be out?

The problem is that your machine doesn't use a Nvidia graphics card. Then, the symptom is the same but the root cause might be completely different. For example, maybe a virus scanner slows down the whole process and there is nothing we can do in this case... except if the computer used to make your builds is contaminated. I remind that it is totally possible to make continuous integration and produce native bundles for Windows under GNU Linux.