More about image timing

[J. Landman Gay]

Brian Yennie wrote:
> If this is truly just a lock screen issue, wouldn't it stand to reason 
> that the Rev IDE is slower because it has a lot more stacks open and 
> affected? Or am I missing a crucial piece here?
> 
> It would seem that having a bunch of extra stacks open (and in some 
> cases visible, including the toolbar) could easily add 1 millisecond to 
> every 10 loops of a screen altering script...?

Could be, though I suspended the development environment and the timing 
was the same. I also only had one stack open. All the IDE stacks were 
hidden (when I ran the test without suspending) but maybe the engine 
checks them anyway.

After I posted, I downloaded Wilhelm's stack and tried that. His script 
doesn't redraw the screen except for once right at the end of the 
handler when it puts the data back into the image. Locking the screen 
there made no difference in speed.

Then I commented out the entire guts of his handler and left only the 
pieces that got the imagedata and set the imagedata. The repeat loop in 
the middle did nothing but increment a counter, just so it had something 
to do. The difference in speed was still apparent between MC and Rev.

I think that narrows it down in this case to setting imagedata (I think 
Wilhelm said the same thing.) So I searched the revCommon library for 
setprop handlers, but didn't notice anything relevant. Because he said 
the behavior was the same in standalones, I didn't bother with any other 
libraries.

So it's still a mystery. Both IDEs use the same engine, only the 
revCommon handler is inserted in a Rev standalone and appears to be 
harmless, and I can't think of anything else that's different. There 
must be something, I just don't know what.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com