The class comment on HandMorph>>processEvent
"
Process user input events from the local input devices.
	An interesting problem. Morphic is always supposed to run in an event
driven environment but for now it is possible that a Morphic window is
run from MVC so that we have to synthesize events in the sensor. That's
quite a bit of a problem because it means that we'll get endless mouse
events. To compensate for this, EventSensor will always return keyboard
events first if synthesized so if we're running into a mouse event AND
Sensor doesn't have an event queue we can safely break out of the event
processing loop. See also EventSensor>>nextEventSynthesized."

Now that morphic is default start up project, maybe there is time to 
change some of this ?

Karl

Marcel Weiher wrote:
> 
> 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