If you watch for the time to execute your routine by triggering on every
message, you are going to slow your app down to a crawl.
>A side effect of checking only during nil events is that the user may be
entering data or tapping the screen quickly, enqueueing >each event within
the timeout frequency, thus starving your event loop of nil events.
The fact is, your app looses control during user input anyway. Just hold
your stylus on the screen in a single position and watch nothing get
updated!
>You'll burn more cycles halving the timeout frequency than you will
performing a simple "is it time now?" check on every received event.
How? Your suggestion has the app doing the same thing, only more frequently.
What will happen to your timing if you require an event every second, look
for the time to execute on every message and have no use input for several
seconds? If you rely on your method and set EvtGetEvent to time out only
every second, you risk missing your sampling window by up to a second!
There are risks to any method that is not timer/interrupt driven. Using the
method you suggest will skew your sampling rate, Increasing the nilEvent
frequency may burn the CPU for a few extra cycles, but it won't slow your
app (by always checking for the correct execution time on every event) or
cause you to skew your sampling rate by up to one sampling interval.
> enqueueing each event within the timeout frequency, thus starving your
event loop of nil events.
You forget that the user will not typically be entering data during the
sampling operation (not on a 16mHz computer). If the user is interacting
with the Palm during this time, your app will not be executing the local
event loops much anyway. Plus UI elements generate nilEvents Plus Plus the
OS generates nilEvents. Plus Plus Plus how many users enter data or tap the
screen several times a second? (that are not playing some sort of action
game)
-----Original Message-----
From: Jim Schram <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, July 14, 1999 7:14 PM
Subject: Re: Automated serial output
>At 3:33 PM -0400 1999/07/14, Dave Lippincott wrote:
>>If you do it this way, you will have to intercept *every* message
generated
>>by the OS. That will suck up allot of CPU time. Just look for the
nilEvent
>>message. When it is received, check the tick count or clock. If you set
>>the EvtGetEvent timeout to some rate that is at least twice the required
>>frequency, you will almost certainly get the desired timing period.
>
>No, check the tick count at every event if you need to guarantee a specific
frequency. You'll burn more cycles halving the timeout frequency than you
will performing a simple "is it time now?" check on every received event.
>
>A side effect of checking only during nil events is that the user may be
entering data or tapping the screen quickly, enqueueing each event within
the timeout frequency, thus starving your event loop of nil events.
>
>Regards,
>
>Jim Schram
>3Com/Palm Computing
>Partner Engineering
>
>
