>From time to time in response to one of my rants about controlling time in Java 3D, people have recommended that I look at the clocks in the Java Media Framework (JMF) API.
Today, I finally got around to getting that running, and have no progress to report. If any of you have waded through any of my earlier rants and are still wading through this one, my complaints center on 1.) the granularity of the clocks that Java 3D uses to schedule tasks and 2.) the OS-dependency in the VM's implementations of those clocks. I usually go on to whine that the granularity and the OS-dependence make it very difficult to design and deliver hi-fi simulations of physical processes built on Java 3D. Because my principal interest is delivering Java 3D models over the web, I've restricted myself to looking only at the platform-independent (all Java?) version of the JMF. The JMF API provides a set of interfaces for dealing with time and clocks, but the only implemented TimeBase is SystemTimeBase, the same clock that underlies such Java constructs as System.currentTimeMillis(), Object.wait(), and the Java 3D Behavior scheduler. On WinNT and Win2k, its time grain is a little over 15 ms, on Solaris 10 ms, and on Win9x, some odd pattern that begins at 50 or so milliseconds. This is far too ragged to manage if we're trying to construct frames at say 50 per second (20 ms) down to 10 per second (100 ms). My conclusion so far is that the JMF, as-delivered, offers no help. Question now is: Given that there must be high precision hardware clocks on the sound and video cards installed on Java 3D-grade computers, is there another TimeBase accessible to JMF? TIA, Fred Klingener Brock Engineering =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
