Sluggishness of 3.0

Marcel Weiher marcel at metaobject.com
Thu Feb 8 12:46:11 UTC 2001


Hi,

I brought this issue about a month ago when I encountered it during  
my re-write of the MacOS-X VM.

I posted my findings at the time, tracing the sluggishness to the  
event handling code within morphic, though I couldn't pinpoint the  
actual problem.

Now that I have everybody's attention ;-)) let me present those  
findings again:

> 2.	Event propagation
>
> Through some logging, I discovered that events get to the VM
> quickly, even in Morphic.  It is within Morphic's event code that   
> things get sluggish and/or lost.
>
> In particular, the top of HandMorph>>processEvents reports events   
> pretty much as they are input from the VM ( still as 8-element arrays   
> / event-buffers ).  However, they sometimes arrive much, much later   
> at the top of HandMorph>>handleEvent:   (now as real morphic events).   
>  Sometimes they don't arrive at all.  So something must be killing   
> those events in the meantime.   ( I am not talking about mouse-moved   
> events, but clicks).

and

> My VM currently has all its input-sensor support #ifdef'ed out and   
> is therefore purely event driven.  However, MVC, despite it having to   
> rely on a Squeak-side sensor-simulation of the event-input from the   
> VM, is a whole lot more responsive.
>
> Another thing I noticed was that Morphic was synthesizing events   
> from the simulated input-sensor synthesizewd from the VM's events.    
> This changed when I switched to another project and back (it seems   
> the check for wether to get events or simulate them is made at
> project-switch-time, despite this not really having much to do with   
> the projects, and more with the underlying VM running the show).

Sadly, I am out of my depth in trying to understand the code in  
question (several levels of polling/synthesizing/emulating), nor do I  
have any good ideas on how to debug this code without dead-locking  
or otherwise killing the image in question, so my suggestion would  
be:

- simplify the event-handling code
- check what happens between HandMorph>>processEvents and  
HandMorph>>handleEvent:
  - this seems especially sensitive to unpredictable timing interactions
    (for example events arriving while the processing is going on can
     make the loop think it is lagging and start discarding events!)
- simplify the event-handling code
- did I mention simplifying the event-handling code? ;-)

I'll gladly help with the effort, but as I said, I am somewhat out  
of my depth here.

Marcel





More information about the Squeak-dev mailing list