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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
