kodiak@amiga.UUCP (Robert R. Burns) (05/19/88)
Joe Hitchens' blanker2 screen blanking program uses a technique that I want to discourage. In order to determine if a certain period has passed, the number of IECLASS_TIMER intuition events is counted, with the assumption that they occur every 1/10th sec. I suggest that, if using input events for timing functions*, you should use the ie_TimeStamp within them, and look for the explicit delay you want. Take the first time you see, add the desired period, and look for it. The timer.device has functions (AddTime, CmpTime) to help. Although the input.task does reissue timer events for a 1/10th sec tick through the input handler chain immediately after it finishes one, an error accumulates so that they cannot be trusted to occur exactly every 1/10th sec. Specifically, some Intuition actions, e.g. resizing a window, stall the handler loop so long as the user is performing the operation. But Joe, don't be distraught! Please take this as constructive criticism from someone who read the source :-). I know that for a screen blanker, time accuracy is not so important, but in source form it invites propagation of the technique to other applications. I'm thus posting this to comp.sys.amiga.tech not only because there is no comp.sources.amiga.d, but I wanted to share this observation with programmers without worrying users of blanker2. - Kodiak (wearing his Mr. "input.device" hat) * blanker2 was already using input events to detect activity. I would otherwise recommend using the timer.device directly. Intuition's sense of time (CurrentTime()) is picked up from the most recent TIMER, RAWKEY, or RAWMOUSE events it received from the input.device input.task. It's thus not the good source of accurate, monotonically increasing time like the timer.device is.