andreas.raab at gmx.de
Thu Apr 3 22:46:33 UTC 2003
> I just ran up a 2.8 image on my Acorn and it is waaaay more responsive
> than any recent image. This is, I think, largely due to it
> being an MVC based image from _before_ the event system was
> put in. The Controllers are rapidly polling for any input rather
> than waiting on a semaphore. I can get similar response from
> a modern image in an MVC project _IF_ I change the global sensor
> to an instance of InputSensor instead of EventSensor.
Well, there's a simple way to fix this problem if it's really that big.
Part of why EventSensor goes through all the hoops is that it tries not to
loose events. This actually ranges back to the days where we synthesized
events from the state based primitives at high frequency (ouch!). Nowadays,
as (I think) all VMs support the event based prims (and do event buffering
on the VM level) we could in fact go straight for the primitive and wouldn't
have to do any of the possibly expensive stuff.
The simple thing to try here would be adding an eventBuffer to EventSensor's
state and see what happens if you implement all of the "InputSensor
primitive simulations" in EventSensor along the lines of:
self primGetNextEvent: eventBuffer.
(eventBuffer at: 1) = EventTypeNone ifTrue:[^nil]. "get out rapidly"
self processEvent: eventBuffer. "update state"
This should get you _really_ close to InputSensor's performance.
If you want to see if it helps Morphic as well, then just change the
Note: Some of the above could be further optimized here but if it's really
the way EventSensor handles things, you should see a drastical improvement
with these changes.
> Even odder, if I try to run a 2.9 or 3.0 image on my current VMs they
> simply don't work; the 3.0 never opens a display, the 2.9 takes in
> excess of 5 minutes to draw the screen. With the 2.9 vm instead, the
> 2.9 image starts up ok but takes no notice of the mouse! Funny, it
> used to work just fine.
Hm ... perhaps a problem with no-longer indexed primitives?! (BitBlt and
CharacterScanner come to mind). The translation for those is pretty slow as
it involves (I think) a name lookup for each primitive invokation.
> The key to improving things is Profiling.
And understanding what's going on ;-) One of the things that's problematic
with MessageTally is that it doesn't show you what's happening besides the
process you're profiling. If, for example, the above really makes a
difference then MessageTally is to blame ;-)
More information about the Squeak-dev