I'm wondering if anyone has suggestions for maximizing the responsiveness of controls during a tight "send in..." loop.
I just discovered an odd (but perhaps expected?) relationship between the send command and locking the screen. It seems that placing "send in..." within a handler that locks and unlocks the screen significantly increases screen refresh performance compared to executing the send AFTER unlocking the screen. I suppose this might be due to Rev being able to cue the next send before updating the screen but I would have expected send to operate independently of the screen update. At first I was thrilled to uncover this, as I've spent the last day trying to enhance the performance of a heavily animated stack, but I was quickly disappointed to find that controls on the card become extremely sluggish and less responsive when the send occurs before the screen unlock. For example, a custom slider bogs down heavily and doesn't respond properly, compared to when the send occurs AFTER the screen unlock. I tried creating a temporary condition (controlActive) that is established when a control is clicked, which the send handler could check and then adjust the timing of the unlock screen appropriately. But so far I'm not seeing any change in the (poor) behavior. I will continue testing. Has anybody else run into this? What strategies do you employ to get the best responsiveness out of your apps during tight repeat loops? Thanks & Regards, Scott Rossi Creative Director Tactile Media, UX Design _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
