Eddie Cottongim wrote:
> Ned wrote:
> 
> 
>>Not if you're saying that localEvt is invariant.
>>
>>localEvt may be changed when it's passed to the child (set the handled
>>flag, install a handler).
> 
> 
> For the handled flag, the dispatchers seem to use that as a terminating
> condition. I have no idea how unsafe installing handlers would be.
> 
> 
>>Also, the transform could very well change as a reaction to a handled
>>event (for instance, a keystroke on a scrollbar). Whether we could
>>assume that the transform didn't change when the event wasn't
>>handled, I don't know (it's possible but not polite for a morph to
>>react to an event but not say it handled it).
> 
> 
> Wouldn't that mean that the order of submorphs would make a big difference
> in how events work? One early in the list can change the rules for the
> others. Well, I guess thats possible.
> 
> Maybe defining things a little more strictly would allow some optimizations.
> I suppose the more generic the framework, the poorer it may be expected to
> perform.
> 
> I was hoping it was an area to be improved. I'm getting 60% CPU just
> twiddling the mouse around the world and its sad.

Where's the CPU being eaten?

What's your OS and VM?

On some VMs you'd see multiple mouse-move events at the same position. I posted 
a simple fix that filtered out these duplicates, though it would of course be 
best to get the VMs not to emit such events if possible.

Did you try the FasterMouseOver (or whatever I called it) change set? I'd be 
curious as to whether that helps your situation.

You can open a profiler from the World/Debug menu and see where the time's going.