FrontScripts speed
Tim Bleiler
Bleiler at buffalo.edu
Tue Apr 8 14:40:02 EDT 2008
Thanks for the help Richard.
That's what I was thinking also. I think I solved the problem since I
posted the request but if anyone is interested this is what I did.
The inserted front script contains a preOpenCard handler that
rearranges controls. I went this route because I was having problems
with controls "jumping around" after doing a lock screen, go to card,
rearrange controls, unlock card strategy (don't know what the problem
is with that either). I thought by having the rearrangement occur in
the PreOpenCard handler I could avoid the problem. I didn't want the
PreOpenCard handler hanging around so I was inserting it into the
front, doing the work, then removing it. When I first tried it I
didn't think I would need any lock screens because the rearrangement
was in the preOpenCard handler. It turns out that's wrong. When I
added a lock screen to the preOpenCard handler the performance
returned to acceptable levels.
Thanks for the comments,
Tim Bleiler
University at Buffalo
On Apr 8, 2008, at 1:17 PM, Richard Gaskin wrote:
> Tim Bleiler wrote:
>> Anyone have any ideas why a script inserted into the front would
>> run MUCH slower than the same script run from a stack script
>> placed in the message path with "Start using"?
>
> Execution speed is pretty much unaffected by the location of the
> handler in the message path, with the only exception being a very
> minor (barely measurable) increase in performance the closer a
> handler is to the front of the queue. This means, however, that a
> frontScript would be a tiny bit faster than a library or backscript.
>
> So whatever's causing the perceived slowdown must be related to the
> interaction of the script with others in the message path.
>
> What does the script do?
>
> --
> Richard Gaskin
> Managing Editor, revJournal
> _______________________________________________________
> Rev tips, tutorials and more: http://www.revJournal.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list