FYI: writing to and reading from fields much faster than locals, globals or custom properties
josh at dvcreators.net
Fri Feb 19 22:07:49 CST 2010
I learned coding from an old guy in an alley, that's why. :-)
When a handler is not event driven, but just looping, monitoring something, and keeps calling itself, what is the proper term?
On Feb 19, 2010, at 7:20 PM, Jim Bufalini wrote:
> BTW, it's the *with messages* that is important. Also, your use of *callback
> loop* is interesting. A callback is a handler that is triggered when a
> callback event occurs, much like a mouseUp handler is triggered on a mouseUp
> event. It's never in a repeat loop.
> Aloha from Hawaii,
> Jim Bufalini
>> -----Original Message-----
>> From: use-revolution-bounces at lists.runrev.com [mailto:use-revolution-
>> bounces at lists.runrev.com] On Behalf Of Jim Bufalini
>> Sent: Friday, February 19, 2010 4:56 PM
>> To: 'How to use Revolution'
>> Subject: RE: FYI: writing to and reading from fields much faster than
>> locals, globals or custom properties
>> Josh Mellicker wrote:
>>> What we found was that when writing and reading a custom property, or
>>> variable, in a 1 ms loop, other stack windows became "sluggish" -
>>> difficult to drag by the header bar, very difficult to click buttons
>>> on, rollover states sticking.
>> Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
>> becomes unresponsive. It has nothing to do with the actual speed of
>> variables vs. fields. Please add, somewhere in your repeat loop:
>> wait 0 milliseconds with messages
>>> When we replaced with writing to and reading a text field on a
>>> (still 1ms), the other windows responded perfectly normally, you
>>> drag and click just like no callback loop was running.
>> Yes, because here other handlers are starting and stopping and this
>> the engine opportunity to intervene.
>>> So I just ASSUMED the field was "faster". Maybe the truth is that
>>> custom properties , although faster, somehow interfere with normal
>>> mouse-related processes... or maybe what we found was just specific
>>> our app, although I don't see how that could be.
>> It's the repeat loop itself without any wait or other handlers being
>>> Anyway, I will do some more tests as soon as I can. I just wanted to
>>> post, in case someone noticed "sluggishness" in an app with a fast
>>> callback loop, my advice is, try fields and see if that fixes it - it
>>> did for us!
>> Just add the wait into your repeat loop with vars or custom props and
>> will see it is even faster than fields. ;-)
>> Aloha from Hawaii,
>> Jim Bufalini
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode