On Aug 9, 2006, at 2:58 PM, David Bovill wrote:
The plugin provides a high-precision timer for those developing in
Revolution with enhanced reliability and greatly improved jitter.
The API is
available only in the IDE.
Don't get the basics here Dar? Timing for what??? I am not sure I
want more
jitter in my Rev stacks :)
I'm still learning to communicate.
You can insert into your scripts two timing calls and a call to get
the time between those or a call to display the time. Like this:
on mouseUp
darzTimerStart
open file "test"
close file "test"
darzTimerStop
darzTimerDisplay -- displays the formatted delta seconds in the
plugin
put "open/close time:" & darzTimerSeconds() -- delta seconds to
the message box
end mouseUp
You now can time things that can be done only once:
on mouseUp
darzTimerStart
destroyRocket
darzTimerStop
darzTimerDisplay
end mouseUp
Before, in Windows, because of the 10 to 17 millisecond typical
resolution available in Revolution, you had to create a loop and
destroy a thousand rockets to get this timing. And even then you had
the tiny loop overhead in your timing.
Also, as in the case of the open/close test, sometimes the results
for the first timing are not the same as the results for the second
timing.
A tiny amount is subtracted from measurements for the call overhead.
You can calibrate that amount by putting these lines in the same
script that the timing is in (so it will see exactly the same message
path):
darzTimerStart
darzTimerStop
darzTimerCal darzTimerSeconds()
If you want raw timing then include this in your script:
darzTimerCal 0
Uh, this is actually part of the experiment. I hope to release
somethings with an eBooklet explaining things. And somethings
without. I see most cases need some hints as to why one wants them.
If you try this and get a handler not found, then open the plugin and
change the setting from "Removed" to "Front Script" or "Script
Library". The first is better for timing fast built-in things. The
latter is better for timing scripts that use other scripts. For very
short times, the message path overhead is predominant and it can add
some noise to measurements. It is often hard to predict.
Also, the OS is always doing this and that, so you will see a little
variation.
The display in the plugin is formatted like this:
2,999,999.999 999 999
So if you see something like this:
0.000 015 812
You can quickly see that it is over 15 microseconds.
Some trailing digits are gray depending on the resolution of that
measurement. Those are not significant. The non-gray digits will
turn a color such as red if darzTimer had to use fallbacks to cope
with hardware failure or extreme drift.
You should be able to time durations up to 24 days, but I haven't
tried that.
The plugin just sits there when not in use. It doesn't tie up CPU
cycles. The library when inserted is in the message path and thus
can slow down execution a tiny bit.
Let me know if you need more.
Dar
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
