gl4java-usergroup

Re: [gl4java-usergroup] animation stutters

[Kenneth B. R. <kbr...@al...>]

What animation technique are you using? I recommend using a
GLAnimCanvas with the GLEventListener paradigm for getting the
application code to run. If you're calling repaint() on the
GLCanvas then the thread switching from the application thread to
the AWT thread and back may be affecting your framerate.

See http://java.sun.com/products/jfc/tsc/articles/jcanyon/ for an
example of this technique in the context of terrain rendering.


> I ported some C++/openGL terrain rendering code (uses triangle strips
> from indexed vertex arrays compiled into a display list) over to
> gl4java.  It runs with pretty much the frame speed as the C++ version,
> but it stutters slightly.  
>  
> I've checked to see whether it was GC causing problems - but I turned on
> -verbose:gc and found the GC isn't to blame - GC is happening only
> rarely and not causing any visual discontinuities when it does occur.
>  
> Any other ideas what I should look at to find the problem? 
>  
> System: Java 1.4.1, gl4Java 2.8.2.0, Windows 2000, NVidia Geforce 256

Re: [gl4java-usergroup] animation stutters

[Kenneth B. R. <kbr...@al...>]

> I'm using the GLAnimCanvas with the GLEventListener paradigm (sorry -
> should have mentioned that)
> 
> I've set the canvas to not receive repaint events, and not to limit fps
> (i.e. go full speed).  Perhaps it might run better if I did limit fps?

Probably not. If your application is multithreaded you may find
it necessary to either adjust thread priorities or repartition
the work that is being done by the various threads. Also take a
look at the JCanyon demo and see whether any stuttering visible
in that demo is similar to the behavior in your application.

RE: [gl4java-usergroup] animation stutters

[Peter <kaf...@xt...>]

 
> Probably not. If your application is multithreaded you may find
> it necessary to either adjust thread priorities or repartition
> the work that is being done by the various threads. Also take a
> look at the JCanyon demo and see whether any stuttering visible
> in that demo is similar to the behavior in your application.

Well, I finally got the demo downloaded (it took a while on my ancient
14.4kb modem!)

It ran extremely poorly - but reading the web site, I see that my
machine is under-specced (I have 128mb ram not the 192 recommended -
it's also a PIII500 as opposed to the 2ghz test machine)  The end
result: the test is inconclusive.

I suppose the next step is to profile my java code and find out where
its spending its time and see if that's something I can fix.

Does anyone know of any particularly good java profilers?

Peter.

[gl4java-usergroup] Re: animation stutters

[Alban <aco...@wa...>]

Hi Peter,

Here is a little checklist that might help you solving your problem :

Your animation may be stuttering because of frequent runs of the garbage
collector. This can happen if you create and destroy a lot of objects per
frame. To avoid this, make sure you never create any temporary objects in
your rendering loop, having a preference using values that are global to
your classes.
Running your program using the option -Xincgc will smooth the garbage
collection over time (but also reduce performance) and this can help you
figure out if the gc is responsible of your problem.
-> java -Xincgc yourclass

You don't need to compile arrays into display lists (this is really useless=
,
I have not noticed any percent of performance increase testing this
feature), but it is always good to lock your vertex arrays. It allows the
driver to optimize the vertex data access in memory and thus gain
performance.

Make sure you don't recompile your display lists at each frame (this a
stupid advice, but we never know...)

Make sure your hard disk drive is not swapping during the rendering, this
would explain the poor / unregular access to the vertex data in memory.
If so, add more RAM to your computer.

Allocate more RAM than needed to the virtual machine, I've had the feeling
it was increasing a bit the performance. For this, use the flag -Xmx
-> java -Xmx256000000 yourclass  (to allocate 256Megs of memory to the
program)

Make sure you don't have 3dsMax or any third party openGL application
launched in the background when you execute your program. In some cases,
3dsMAX make me loose up 70% of my application performance, and I hask mysel=
f
"what the f%% is going on ?"..."oh max is running in the background..."

Don't use too small arrays. Small counts of polygons like 50-200 won't make
you benefit of a real performance increase. Prefer having several thousand
faces per array if possible.

I'm personnaly using vertex arrays having very good and smooth performance
under a geForce2MX. What 3d card do you have ?

Regards,

Alban Cousini=E9
Mind2Machine

[gl4java-usergroup] RE: animation stutters

[Peter <kaf...@xt...>]

> Hi Peter,
> 
> Here is a little checklist that might help you solving your problem :
> 
> Your animation may be stuttering because of frequent runs of the
garbage
> collector. This can happen if you create and destroy a lot of objects
per
> frame. To avoid this, make sure you never create any temporary objects
in
> your rendering loop, having a preference using values that are global
to
> your classes.
> Running your program using the option -Xincgc will smooth the garbage
> collection over time (but also reduce performance) and this can help
you
> figure out if the gc is responsible of your problem.
> -> java -Xincgc yourclass


I checked out whether GC was the problem as the first step (I mentioned
that in the initial post on this subject).  I have been running with
-Xincgc from the outset.  I also explicitly turned on -verbose:gc so I
could see when it was gc'ing, but I discovered that it gc'd rarely (I
don't create much at all during my main rendering loop) and that the
stuttering continued between gc events.

 
> You don't need to compile arrays into display lists (this is really
> useless,
> I have not noticed any percent of performance increase testing this
> feature), but it is always good to lock your vertex arrays. It allows
the
> driver to optimize the vertex data access in memory and thus gain
> performance.

Actually I got a very large speed increase when using display lists
(which is what I expected since Nvidia explicitly recommend it as being
faster than just using arrays - compiled or not)


> Make sure you don't recompile your display lists at each frame (this a
> stupid advice, but we never know...)

heh - don't worry, I'm not doing that =)


> Make sure your hard disk drive is not swapping during the rendering,
this
> would explain the poor / unregular access to the vertex data in
memory.
> If so, add more RAM to your computer.

It's not reading from disk (the terrain is generated from an fbm
fractal)


> Allocate more RAM than needed to the virtual machine, I've had the
feeling
> it was increasing a bit the performance. For this, use the flag -Xmx
> -> java -Xmx256000000 yourclass  (to allocate 256Megs of memory to the
> program)

I'll try that - I had it in mind that I wasn't using a lot of memory,
but that may be an invalid assumption.


> Make sure you don't have 3dsMax or any third party openGL application
> launched in the background when you execute your program. In some
cases,
> 3dsMAX make me loose up 70% of my application performance, and I hask
> myself
> "what the f%% is going on ?"..."oh max is running in the
background..."

Heh - no, not doing that either.


> Don't use too small arrays. Small counts of polygons like 50-200 won't
> make
> you benefit of a real performance increase. Prefer having several
thousand
> faces per array if possible.

There's no issue with the openGL performance of this code - it's a port
of C++ code which was rendering in exactly the same way and performing
fine.  Actually, it's not even that the Java version is *slow* - it
isn't - It achieves pretty much the same fps as the c++ version, it just
stutters and doesn't run smoothly.  It's like it's dropping a frame
every now and then.

 
> I'm personnaly using vertex arrays having very good and smooth
performance
> under a geForce2MX. What 3d card do you have ?
> 

Geforce 256 / Windows 2000 / 128mb ram.

Cheers,

Peter.

[gl4java-usergroup] RE: animation stutters : FIXED

[Peter <kaf...@xt...>]

Just thought I'd let everyone who has replied know that I've fixed the
animation stuttering problem - it was my fault and being caused by my
input loop.  I had been polling for input at 30hz, which isn't a problem
per se, except that I was only updating the camera position when I
polled the input - hence the stuttering. 

With that little bit of genius rectified, it now works fine.

Thanks to everyone who replied =)

Peter.


---
The existence of morning is final and incontrovertible proof of the
non-existence of a benevolent god.