Real Slowdown of InputSensor between 3.8 and 3.9

John M McIntosh johnmci at
Tue May 1 15:33:20 UTC 2007

On May 1, 2007, at 6:31 AM, Stéphane Ducasse wrote:

>           |  |  89.2% {19003ms} EventSensor>>wait2ms
>           |  |    89.1% {18982ms} Delay>>wait

Ok that is a change I submitted oh back in 2005,  


The original issue was that in the browser when you moved the cursor  
between window panes the
logic that is responsible for setting the resize pane cursor and  
deciding if the mouse was down would
loop and call primMouseButtons and primMousePt. Under certain  
conditions it would grab the mouse so to speak
and run 100,000 of primMousePt calls, however that would prevent the  
image  from actually servicing any
real mouse movements thus decoupling the squeak mouse location from  
the hardware mouse location

However as you noticed this has a side effect when your code assumes  
looking for the state of the modifier keys
takes 0 milliseconds. Gary's solution could be considered but you  
need to see who the callers are to avoid excessive polling,
perhaps you'll need a call to look and wait the 2ms to avoid  
excessive polling but make that an explicit request and use on
an as needed basis.

Also Gary's code only considers the cached state of the button and  
modifiers, without reasking the VM for the information, that
assumes state changes will at some point flow up to the cached value  
as part of the normal EventSensor processing.
Technically that should happen anyway, and I'd guess peformance is  
better than the original code which attempts to ask the
VM for the current sensor state which can be time consuming.

Mmmm I wonder how much Sensor peeking is going on in a 3.9 image and  
how the wait2ms is affecting things?

John M. McIntosh <johnmci at>
Corporate Smalltalk Consulting Ltd.

More information about the Squeak-dev mailing list