Initial startup delay in running JoGL app

Hi all

I have been experimenting with JoGL 1.1b10. It seems to take a lot of time to load app (in some instances a couple of minutes for a basic GLPanel).

I thought it might be something to do with the nVidia graphics card of my tablet PC which is running on Windows XP, Service pack 2. Downloaded gl4java to check and it seems to work fine.

Then I went back to JoGL download site and installed v1.0 (April 2004) - both natives and the jar. It seems to be working fine now.

I was wondering, has anyone faced similar problem or is it just me?

FYI, the tablet PC is running with the following configuration:

RAM: 1GB
VGA: nVidia GeForce 4 420 Go 32 MB
OS: Win XP Tablet PC, SP2
Java: Java 1.5 (5.0)

Regards
Monjur

What NVidia driver version are you running ?

I just started getting a startup delay with JOGL having rebuilt my Win2K machine after a crash, and having moved from driver 66.93 to 71.84.

I’ve yet to see if going back to 66.93 fixes the issue.

Rob

Update to the above post:

1. jogl 1.0
Not supporting GLJPanel. I get “Unable to set pixel format” error. When I use GLCanvas in the same app, it works fine.

2. jogl 1.1b09 and 1.1b10
GLCanvas seems to be working fine. With GLJPanels, the above v1.0 error of “unable to set pixel format” is gone but it takes an awful long time for the app to startup.

Monjur

Hi Ron

Display driver version: 6.14.10.4574

Drivers: nv4_mini.sys, nvoglnt.dll, nvcpl.dll, nvrsenq.dll, nview.dll, nvsell.dll

Any thoughts?

Monjur

I just upgraded to NVidia’s 71.84 drivers with no problems. I think there are two issues here. Monjur, you probably need to upgrade to more recent drivers to get reasonable pbuffer support, which is used by the GLJPanel but not the GLCanvas. Rob, is your application computing a lot of mipmaps during startup? The Java port of the GLU mipmap routines new in JOGL 1.1 b09 is somewhat slower than the C version.

Ken,

I’m not using GLU to generate my mipmaps or anywhere else, so it’s not that. I seem to have lost about 60% off my frame rate as well, so I’m very puzzled.

I’ll dig some more and start another thread if it seems appropriate. Thanks for enquiring.

Rob

Ken,

I’ll post here since this may be the same monjur’s problem.

This issue I’m seeing is that the setVisible() call on my JFrame can take up to 45 seconds to execute. It doesn’t happen every time, and when it does happen pressing ctrl-break to try to get a stack dump does nothing until the frame appears at the end of the delay, when the stack information then spews out.

Sometime the delay occurs in the immediately preceding pack() call.

This is with a cleanly installed machine built from scratch yesterday with:

Win2K Pro (With all latest Windows Update maintenance)
JOGL 1.1 b10
NVidia drivers 7184
Java 1.5.0_02

Previously before my machine rebuild, I was running with the same JOGL but Java 1.5.0, and 66.93 drivers. I don’t know if any of this is relevant. I’m going to try regressing levels.

The frame rate degradation was a red-herring - I was using ‘-Dsun.java2d.opengl=true’ which was causing this and which I have now removed, but the start-up delay remains.

Very puzzled over this.
Rob

OK,

I’ve just rolled back to 66.93 drivers, and I can’t reproduce the problem…

Rob

Are you running with -Dsun.java2d.noddraw=true with the 71.84 drivers? Does that change the behavior?

Something is almost certainly going wrong at the driver level. A hang like that means that the JVM process isn’t getting any CPU time; ordinarily it will be able to provide a thread dump when threads are down in native code.

Rob and Ken

Thanks very much for your inputs.

My strategy now is to use GLCanvas instead of GLJPanel and use jogl 1.1b10 with existing drivers. Could not update nVidia drivers as the 71.84 drivers wont install in my machine which is running tablet PC version of WinXP.

May be Ken could give us updates on if there’s anything to do with the native files. In the meantime, I will wait for the next update of JoGL.

Regards,
Monjur Mourshed

Ken,

I’ve been running with -Dsun.java2d.noddraw=true all along under both driver versions. I agree this sounds like a driver issue. Guess I’ll have to stay at 66.93 for now.

Rob