JOGL preload

[Gene]

We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app.
The JOGL part of the system draws on a GLCanvas that's on an initially
hidden tab control. The normal pattern of use is to work in the Swing-
only part of the system and then select the GLCanvas tab to visualize
work so for.

When the user selects the GLCanvas tab, there is a delay of 2 to 20
seconds while the disk clatters and all window activity freezes. Then
all is perfect. Afterward switching among tabs is instantaneous.

So it looks like it's binding dynamic libraries upon the first tab
click when the GLCanvas is first made visible.

The effect is same on XP, Vista, Win 7, 32 and 64-bit and Mac Snow
Leopard (64-bit). We're using most recent versions of Java runtime,
JOGL v1, etc.

What is the best way to have this initialization done before the user
selects the GLCanvas tab? Ideally it should happen in the background
while the user is interacting with the non-JOGL (Swing-only) part of
the system.

I guess we could show a small GLCanvas during startup to force
initialization then, but that's such a horrible kludge, there must be
a better way.

All the best.

 

[Olaf Klischat]

We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app.
The JOGL part of the system draws on a GLCanvas that's on an initially
hidden tab control. The normal pattern of use is to work in the Swing-
only part of the system and then select the GLCanvas tab to visualize
work so for.

When the user selects the GLCanvas tab, there is a delay of 2 to 20
seconds while the disk clatters and all window activity freezes.

That doesn't sound normal. And why the large variance (2 to 20 seconds)?

Then
all is perfect. Afterward switching among tabs is instantaneous.

So it looks like it's binding dynamic libraries upon the first tab
click when the GLCanvas is first made visible.

Have you verified this? Try running the program in a profiler like
jvisualvm and maybe in a syscall tracer to see where the time is spent.
The system shouldn't spend two, let alone twenty, seconds linking in
some OpenGL libraries. Are you sure it's not large textures or other GL
data being loaded initially from the filesystem? Does the delay still
occur if you have empty initialization and display methods in the GLCanvas?

 

[Gene]

That doesn't sound normal. And why the large variance (2 to 20 seconds)?



Have you verified this? Try running the program in a profiler like
jvisualvm and maybe in a syscall tracer to see where the time is spent.
The system shouldn't spend two, let alone twenty, seconds linking in
some OpenGL libraries. Are you sure it's not large textures or other GL
data being loaded initially from the filesystem? Does the delay still
occur if you have empty initialization and display methods in the GLCanvas?

Thanks for the insight. I tried profiling in the Netbeans
environment. Nothing in the output indicated where the time went.
I'll look at the profilers you suggest.

The 20 seconds is on a lame, old machine with the disk deliberately
nearly full for a stress test with low swap space. The 2 seconds is
much more typical. This app has to run on computers in elementary
schools that tend to be old and slow. Hence the testing regime.

There are textures, but nearly all are tiny. The exception is a sky
map, which is ~ 1/2 megabyte in JPEG form.

Even if it is something like textures loading, the question seems
roughly the same. Textures are loaded (and reloaded) in the init()
method. Is there a way to force the GL context (including textures)
to be initialized before the first paint event causes it to happen?

Thanks again.

If anyone is interested, the app is at http://www.eecs.usma.edu/webs/wpbd
..

 

[Olaf Klischat]

Thanks for the insight. I tried profiling in the Netbeans
environment. Nothing in the output indicated where the time went.
I'll look at the profilers you suggest.

The Netbeans profiler is pretty much a superset of jvisualvm I figure,
so you should be OK as long as you're using it right . It really
helps to become familiar with one of these tools to be able to quickly
analyze situations like this. A two-second block should be easy enough
to isolate even with some System.out.printlns in strategic places. With
jvisualvm, you'd essentially start your app, then find and open it in
the "applications" tab in jvisualvm, select Profiler/CPU, wait until it
has started, click "Reset results buffer", switch to the app and perform
the activity that you want to profile, wait until it has finished,
switch back to jvisualvm, click "take snapshot", open the snapshot and
the "Combined" tab, and look where most of the time was spent (if some
native GL call took most of the time, it should appear prominently in
the "Hot Spots" pane).

The 20 seconds is on a lame, old machine with the disk deliberately
nearly full for a stress test with low swap space. The 2 seconds is
much more typical. This app has to run on computers in elementary
schools that tend to be old and slow. Hence the testing regime.

There are textures, but nearly all are tiny. The exception is a sky
map, which is ~ 1/2 megabyte in JPEG form.

Even if it is something like textures loading, the question seems
roughly the same. Textures are loaded (and reloaded) in the init()
method. Is there a way to force the GL context (including textures)
to be initialized before the first paint event causes it to happen?

Not AFAIK. Well, there is GLDrawableFactory#createOffscreenDrawable(),
but that's quite...adventurous to use I think. Still, since you say that
the canvas is fast when opening it the 2nd..nth time, the bottleneck
probably isn't GL operations like uploading textures to the GPU
(glCreateTexture()) or the like. The first thing I would check is
whether the delay still occurs if you completely empty the init() and
display() methods. If the problem really is some JPEG decoding before
the glCreateTexture() call, there are ways to do that before the GL
context is created the first time. If you use JOGL's texture classes,
you should be able to create the TextureData before a GLCanvas is
created (that should uncompress any JPEG data), and only create the
Texture object in the init()/display() method.

 

[John B. Matthews]

We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app.
The JOGL part of the system draws on a GLCanvas that's on an initially
hidden tab control. The normal pattern of use is to work in the Swing-
only part of the system and then select the GLCanvas tab to visualize
work so for.

When the user selects the GLCanvas tab, there is a delay of 2 to 20
seconds while the disk clatters and all window activity freezes. Then
all is perfect. Afterward switching among tabs is instantaneous.

So it looks like it's binding dynamic libraries upon the first tab
click when the GLCanvas is first made visible.

The effect is same on XP, Vista, Win 7, 32 and 64-bit and Mac Snow
Leopard (64-bit). We're using most recent versions of Java runtime,
JOGL v1, etc.

What is the best way to have this initialization done before the user
selects the GLCanvas tab? Ideally it should happen in the background
while the user is interacting with the non-JOGL (Swing-only) part of
the system.

I guess we could show a small GLCanvas during startup to force
initialization then, but that's such a horrible kludge, there must be
a better way.

I have little JOGL experience, but this may be related to mixing heavy
(AWT) and light (Swing) components, GLCanvas and JTabbedPane:

<http://java.sun.com/products/jfc/tsc/articles/mixing/>

javax.media.opengl.GLJPanel might be an alternative.

 

[Daniel Pitts]

Thanks for the insight. I tried profiling in the Netbeans
environment. Nothing in the output indicated where the time went.
I'll look at the profilers you suggest.

The 20 seconds is on a lame, old machine with the disk deliberately
nearly full for a stress test with low swap space. The 2 seconds is
much more typical. This app has to run on computers in elementary
schools that tend to be old and slow. Hence the testing regime.

There are textures, but nearly all are tiny. The exception is a sky
map, which is ~ 1/2 megabyte in JPEG form.

Even if it is something like textures loading, the question seems
roughly the same. Textures are loaded (and reloaded) in the init()
method. Is there a way to force the GL context (including textures)
to be initialized before the first paint event causes it to happen?

Sounds like you might need to tune your JVM memory settings.
There are plenty of good documents available, I'll let you google for it
yourself.

My thought is that maybe your program is allocating enough
objects/memory, fast enough that the JVM has to resize its heap(s)
several times. If you can set your initial heap size to just over the
peak start-up heap size, you might see start-up time improvements.

 

[Gene]

Sounds like you might need to tune your JVM memory settings.
There are plenty of good documents available, I'll let you google for it
yourself.

My thought is that maybe your program is allocating enough
objects/memory, fast enough that the JVM has to resize its heap(s)
several times.  If you can set your initial heap size to just over the
peak start-up heap size, you might see start-up time improvements.

Great point. This is my first serious Java project, so I'm not used
to tuning GC. Thanks very much.

 

[Gene]

Sounds like you might need to tune your JVM memory settings.
There are plenty of good documents available, I'll let you google for it
yourself.

My thought is that maybe your program is allocating enough
objects/memory, fast enough that the JVM has to resize its heap(s)
several times.  If you can set your initial heap size to just over the
peak start-up heap size, you might see start-up time improvements.

Thanks again. Increasing the initial heap size helped a lot.

 

[Daniel Pitts]

Thanks again. Increasing the initial heap size helped a lot.

Glad to hear it. Thanks for the follow up.