Recently, Richard Gaskin wrote: >>>> I guess Scott was concerned about the smoothness of the time display >>>> ticking over. If you send every 1 second, and there is something holding >>>> up message processing, the timer may be late to update. Increasing the >>>> frequency increases the chance of getting it right (but doesn't >>>> guarantee it). >>> >>> Wouldn't any issues that would delay the firing of a one-second timer >>> also delay a 1/10th second timer as well? >> >> >> It could, but if one is after one second accuracy, for example, the >> one-second timer will be thrown off, whereas the 1/10-second timer has the >> opportunity to correct itself (assuming whatever issues delay the timer >> don't take 3 seconds to execute). > > If a message were completely removed from the queue that would be an > issue. But if the message is merely delayed until the next idle, > wouldn't all messages that are due for firing get fired in their firing > order, regardless of the wait period specified when they were queued?
I don't quite follow what you're asking here (like Dave, my brain is starting to ache), but it prompted me to try something else: on runTimer if not the uAllowTimer of me then exit runTimer send "runTimer" to me in 100 millisecs put the long time into fld 1 end runTimer This handler immediately triggers itself again before doing anything, so in theory, it should remain relatively consistent while being called only once per second. However, taking a look at the CPU usage shows this simple routine runs around 14% to 15% or so processor usage. The "wait x with messages" apparently uses next to nothing. So while efficient script-wise, "send in" appears to require significant more engine power to run. That's my take on this anyway without knowing the details about Rev's inner workings. You may say "what's the big deal about 15% CPU usage?" It may not be an issue for many folks. In my case, it is a big deal: moving images around a card, swapping the icons of buttons, scrolling text in fields, all this stuff adds up and places higher demands on the engine. Anything I can do to reduce these demands enhances the ability of my apps to play nice with others. FWIW, I've come across other things that contribute to CPU use. From the above, running a timer and updating the time in an unlocked field requires about 4 to 5 times as much usage as when placing text in a locked field. Locking the screen before updating a number on on-screen items can place very high demands on CPU usage if done frequently. You may recall the jukebox project I posted some time ago -- I consistently ran into memory problems when trying to move all those bubbles around the screen. I tried everything I could of the get the processor use down and on a whim tried removing the "lock screen" instructions from my scripts. Not only did processor use become manageable but Rev was fast enough to update the 25 or so images without major delay. This may not work for all situations but it's a good trick to keep in mind. Regards, Scott Rossi Creative Director Tactile Media, Development & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution