From:  Dean Swan at MITEL on 11/22/99 01:02 PM

There was some discussion about the Win32 VM and UI performance back in
September.

What follows is an excerpt from a message I sent to Andreas:

>
>     Time millisecondsToRun:
>     [
>       1 to: 1000 do:
>       [ :x | Sensor mousePoint ]
>     ].
>
>returned results on 4 consecutive runs of:
>
>     Casio E-105, 2.5 img, 2.4c VM       49995, 49985, 50005, 50000
>
>     PII/450, NT Ws4.0 SP 4              5017, 5017, 5027, 5018
>       2.5 img, 2.5 VM
>

Interestingly, if I touch the pen to the screen while this loop is running, (on
the E-105) I get results like 410, 295, 330, 320.

I also tried the tests that John Maloney suggested with a 'BouncingAtomsMorph'
running.  His "noop" loop didn't have any noticeable effect on the speed of the
BouncingAtomsMorph, but his 'Sensor buttons' example literally brought the morph
to a complete stop until the screen was tapped.

What seems to be happening is that when the VM calls
'MsgWaitForMultipleObjects()' in from 'ioMousePoint()' with a wait timeout of 5
ms, the E-105 will actually wait for up to 50 ms if no events get queued.
Touching the screen with the pen must queue up enough events to cause it to
return nearly immediately.

Regarding Andreas's question: "What can we do about it?" - one thing would be to
only actually poll for mouse events 20 or 30 times per second, based on a timer
driven process.  Checking any more frequently than that isn't productive,
because a typical serial mouse sends a 6 byte report @ 1200 bps for changes in
buttons or mouse location, which gives you at most, 20 reports per second.  Even
for newer, faster mice that communicate at 9600, that would still be only 160
events per second.

As for the "draining the batteries" issue, I would suggest letting
'ReliquishProcessorForMilliseconds:' take care of that.  If sending 'mousePoint'
to 'Sensor' caused the calling process to wait on a Signal that a mouse event is
ready, then the idle process would be running most of the time, especially if
the more expensive hardware polls are only done less than 100 times per second.
Since this would cause the original process to block on a semaphore, the VM
would allow other processes to run, keeping the system from locking up.  I think
this sort of thing could make a big difference in performance because 'Sensor
mousePoint', 'Sensor buttons' and the like are sent *VERY* frequently.

I learned this in a painful way this weekend while working some more on my
software displayed cursor for the E-105.  I was working on my Pentium 133, and
hooked up my cursor display routine (which saves the screen background to a form
in an instance variable, then draws the cursor to Display) into
'InputSensor>>mousePoint'.  It essentially locked up the machine because of the
huge amounts of garbage generated by creating a new temp form every time
'mousePoint' was sent.



                                         -Dean Swan
                                         dean_swan at mitel.com