Re: [gl4java-usergroup] Errors

[Virgil W. <vir...@ra...>]

> Dear Virgil,
>
> I want to encourage you to use GLAnimCanvas,
> or hte way GLAnimCanvas uses the animation update methods !
>
> I see it in many demos, that you use the threaded sDisplay call for
> default !
> This only works within a very good native multithreading JVM,
> and does steals a lot of ressources ...
>
> You can see, that the GLAnimCanvas demos does have the option to
> refresh directly (useRepaint... method), but it is disabled for default.
>
> I think, that the repaint method should be fast enough for us ... >= 20
> fps :-)
>
> Of course, the direct way gives us quiet the same fps, like the native
> application, but we do pay responsiveness of the JVM for it !
>
> Please check the PERFORMANCE mail from me to the mailinglist,
> and the PerformanceLog's within the demos/MiscDemos directory !
>
> Yours, Sven

Well, the reason I have to call sDisplay in a loop is that I need to very
accurately track how long it takes to do the display.
GLAnuimCanvas tracks frames per second by using System.currentTimeMillis().
This only yields timing accurate to around 16ms (on a good day).  This isn't
really that good (for a game anyway).  Since I'm writing a game, I want very
high frame rates and I need to know very precisely how long each update
takes (so I can move game objects at the right rate).  To solve this
problem, I make a call into a jni library I've written to more accurately
calculate time.  (Using the system clock on windows to achieve near
microsecond accuracy).
Also, I do a Thread.sleep() once per loop (in order to set a maximum fps).

In summary, I pretty much do what GLAnimCanvas does, I just need to be able
to very precisely track how long each update takes (and using
System.currentTimeMillis() isn't good enough)

(For the curious, the Magician Java opengl crap has a percision timer
call... it's pretty each to do, but one might argue that it has nothing to
do with opengl)


Virgil