0

I'm having issues with long load times with my JOGL application. Everything worked fine until yesterday, when canvas initialization suddenly started taking whole minute. The culprit is somewhere inside of native Platform.initSingleton() call.

Following code in clean class

System.out.println("Start");
long t0 = System.currentTimeMillis();

AbstractGraphicsDevice device = GLProfile.getDefaultDevice();
long t1 = System.currentTimeMillis();
System.out.println((t1 - t0) + "ms " + device);

GLProfile profile = GLProfile.getDefault(device);
long t2 = System.currentTimeMillis();
System.out.println((t2 - t1) + "ms " + profile);

GLCapabilities capabilities = new GLCapabilities(profile);
long t3 = System.currentTimeMillis();
System.out.println((t3 - t2) + "ms " + capabilities);

System.out.println("Java version "+System.getProperty("java.version"));

will produce

61467ms WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x59b9040a]]
0ms GLProfile[GL4bc/GL4bc.hw]
0ms GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]]
Java version 1.8.0_102 / 1.8.0_121 / 1.8.0_152

I tried

  • running at different computers with similar specs (works over there just fine)
  • debug to find more specific place inside of the call, but got stuck at native call to Platform.initSingleton()
  • run Platform.initSingleton() with -Djogamp.debug=ALL (see below)
  • checked all libraries to be same as on working machines
  • updating JDK and JRE to newest version
  • reinstalling JDK and JRE to older version
  • updating windows
  • updating graphics driver to newest
  • reinstalling (clean) graphics driver to version with which it is working elsewhere
  • according to windows update history were installed KB4038788, KB890830, and KB4038806, none hint they could be the reason
  • firewall does not seem to be blocking any system calls (off just to be sure)
  • windows defender off to be sure
  • compiling the test code into jar and running it from command line

It seems from debug prints, that the problem is somewhere in here

IOUtil.testDirExec(): test-exe <C:\Users\User\AppData\Local\Temp\jogamp_exe_tst3558906654350516679.exe>, existingFile false, returned 0
IOUtil.testDirExec(): abs-path <C:\Users\User\AppData\Local\Temp>: res 0 -> true
IOUtil.testDirExec(): total 30033ms, create 16ms, fill 0ms, execute 30017ms
IOUtil.testDirImpl(tempX1): <C:\Users\User\AppData\Local\Temp>, create true, exec true: true
IOUtil.testDirExec(): test-exe <C:\Users\User\AppData\Local\Temp\jogamp_0000\jogamp_exe_tst3791240964894525069.exe>, existingFile false, returned 0
IOUtil.testDirExec(): abs-path <C:\Users\User\AppData\Local\Temp\jogamp_0000>: res 0 -> true
IOUtil.testDirExec(): total 30016ms, create 0ms, fill 0ms, execute 30016ms

I'm running out of ideas, and I'm not exactly fond of the idea of reinstalling my whole system just to get back up, possibly encountering it again.

Any idea, experiences with that might cause this? What I find the most interesting is, that it eventually works, and initialization process is just delayed.

Using oracle JDK 1.8.0_102 / 1.8.0_121 / 1.8.0_152 (same on all, 121 worked a couple days ago) Tried drivers 388.13x64 (newest) and 385.69x64 (works on different machine)

Edit: Machine where it does not work has GTX 1070, one where it works GTX 960.

Vojtěch Kaiser
  • 568
  • 3
  • 15

1 Answers1

1

After some more digging, I found the best solution to be to add

-Djogamp.gluegen.UseTempJarCache=false

to JVM arguments.

to quote from similar question (which I did not find for some reason when asking this question) JOGL takes too long to start

Marvin Meller:

Launching with the argument -Djogamp.gluegen.UseTempJarCache=false and using the native libraries instead of jars has done the trick for me (startup time from 15s+ to 500ms). It's not really a solution since the native libraries shouldn't be used anymore but it's still enough to debug.

The problem in original question seems to be a bit different than mine, as I have fixed 30+30 seconds caused by timeout in cache access instead of long running anti-virus check.

Vojtěch Kaiser
  • 568
  • 3
  • 15
  • Please can you indicate which graphics card you use? – gouessej Jul 01 '18 at 08:27
  • Added in the question. – Vojtěch Kaiser Jul 02 '18 at 07:33
  • There is a bug affecting this kind of hardware but our bug tracker is still offline :s However, as the only solution consists in disabling the automated native library loading, it's probably caused by a virus scanner despite the slightly different symptom. – gouessej Jul 04 '18 at 12:17
  • In the question: "firewall does not seem to be blocking any system calls (off just to be sure)", and I do not use antivirus program. It might be possible windows antivirus thing (never really bothered to investigate it) might be throwind a wrench in the setup, but when similar calls are blocked, windows usually lets me choose. Will give it a look. – Vojtěch Kaiser Jul 04 '18 at 16:39
  • Are you absolutely sure that Windows Defender is disabled on this machine? – gouessej Jul 06 '18 at 11:13
  • Checked again, no firewall or windows defender feature were enabled (as far as windows can be trusted). Will try to find a machine it works on and add longer list of differences to the question. – Vojtěch Kaiser Jul 10 '18 at 20:41