Hi Fred,
A separate TimerThread is used for wakeupOnElapsedTime,
the timer start when the user program invoke
wakeupOn(WakeupCondition criteria)
the request is then sent to the TimerThread for
wait(waitTime);
The scheduler is wakeup as soon as possible to invoke
the user callback processStimulus() for another
wakeupOn().
There is overhead for
(i) Time from the user program invoke
wakeupOn() to Object.wait(waitTime)
(ii) Time from the TimerThread wait up
to the BehaviorScheduler schedule the
callback processStimulus()
(iii) Time from the start of processStimulus() to
the next call wakeupOn()
There is also other activities which may contribute
to the delay, e.g. rendering
But internally there is no minimum 15ms latency for
the scheduler, it wakeup ASAP. I guess the problem
may be the rendering thread is waiting for the
vertical retrace sync of your monitor that cause this
quantization problem. You may try to set option
in the driver setting to turn this off. Under solaris
you can do this by
setenv OGL_NO_VBLANK
For the first problem (1), can you please elaborate
a little bit. A test program to demonstrate this problem
would be great.
Thanks.
- Kelvin
----------------
Java 3D Team
Sun Microsystems Inc.
>X-Unix-From: [EMAIL PROTECTED] Thu Sep 28 07:31:22 2000
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>Date: Thu, 28 Sep 2000 10:21:03 -0400
>From: Fred Klingener <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Simulation clocks - continued
>To: [EMAIL PROTECTED]
>
>Remember that in the last episode, Freddie had replaced the standard
>Interpolators with a set of Behaviors that maintained a separate simulation
>clock using a wakeupOnElapsedTime(time_step) criterion, rather than the
>wakeupOnElapsedFrame(0) used by the standard ones. As we left him, Freddie
>was puzzling over the odd results: 1.) the introduction of Behaviors that
>use the wakeupOnElapsedTime(time_step) criterion evidently stopped the
>rendering thread's characteristic free-wheeling behavior as evidenced by the
>recovery of a significant portion of the CPU capacity, and 2.) there was an
>odd relationship between the specified time_step and the actual elapsed time
>(as measured by the System clock) that the Behavior's processStimulus() got
>executed.
>
>As we look in on him now, he's laboriously stepping through values of the
>scheduled time_step and logging the observed difference in System clock
>readings between processStimulus() calls. [Zoom in on the scrap of paper in
>his lap. Toward the bottom is the graph:]
>
>(sorry about the graph, if you don't have exactly the font I used to
>construct it)
>
> 46 + *******
> |
> Delta Time |
> on the 31 + ********
> System |
> Clock |
> (milliseconds) 15 +*******
> |
> |
> +-------+--------+--------+--------+
> 15 31 46
> time_step
>
>"Hah!" says Freddie as he slaps his forehead. "It's as though the Behaviors
>post their wake up times to a queue, and the scheduler only checks the queue
>every 15 or 16 milliseconds." He turns to Margo, his incredibly beautiful
>ash blonde Chief Technology Officer, and says, "This means that if we don't
>pick the right time_step, we won't be able to synch our simulation clock to
>the System clock. If we pick 31 milliseconds, we'll be almost exactly in
>synch, and at 32 milliseconds, we'll slip by 33%"
>
>Margo sniffed and said, "Well, that's an interesting little cosmetic tidbit
>you've stumbled on there, but the real crux is the effect on the adaptive
>time stepping routines in our IK iterators and the numerical integrators.
>If we don't tiptoe around that 15 milllisecond strobe, our solutions and the
>display will look like garbage, even if they're correct."
>
>"I know you would have figured that out by yourself eventually, but we have
>to get a strategy for dealing with this NOW. Get on JAVA3D-INTEREST and see
>if anyone knows whether this is documented anywhere. Can we count on this
>across platforms? Across versions? Will we have to test each system on the
>fly before we can begin our simulation?"
>
>Margo began to leave but turned and leaned over the cubicle wall. "And
>another thing. You just got the averages over 100 frames. Redo it and get
>the distributions. We have to know how regular this is. Don't worry about
>the delays for garbage collection and system services. They'll probably
>take much longer than 15 milliseconds. They'll be outliers."
>
>"Yes'm."
>
>The closing credits roll as Margo turns and walks back to the daycare center
>adjoining her window office, and Freddie hunches over his keyboard to
>compose...
>
>
>Freddie 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".
===========================================================================
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".
