More on Performance

[Scott Rossi]

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