JOGL preload
in [Java Help]
|
Prev: How to find out from *.class file with which Java version 1.6 or 1.5 it was compiled?
Next: Creating a big file
From: Gene on 4 Aug 2010 12:01 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.
From: Olaf Klischat on 4 Aug 2010 18:39 On 08/04/2010 06:01 PM, Gene wrote: > 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?
From: Gene on 4 Aug 2010 19:51 On Aug 4, 6:39 pm, Olaf Klischat <olaf.klisc...(a)googlemail.com> wrote: > On 08/04/2010 06:01 PM, Gene wrote: > > > 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? 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 ..
From: Olaf Klischat on 4 Aug 2010 21:30 On 08/05/2010 01:51 AM, Gene wrote: > On Aug 4, 6:39 pm, Olaf Klischat<olaf.klisc...(a)googlemail.com> wrote: >> On 08/04/2010 06:01 PM, Gene wrote: >> >>> 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? > > 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.
From: John B. Matthews on 4 Aug 2010 22:44
In article <45c76862-b38c-46b6-bebd-0d8e63b4d543(a)5g2000yqz.googlegroups.com>, Gene <gene.ressler(a)gmail.com> wrote: > 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. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |