FrontScripts speed

[Tim Bleiler]

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
>