On 3/23/2010 10:50 AM, John M McIntosh wrote:
> When the *high priority* task looking at the mouse location in the Browser see the cursor move between the browser windows it would change the cursor. Then invoke a tight loop to see when the cursor reentered a browser pane. This would drive 100,000 peekPosition  starving the regular morphic loop.  The result was that at the time the cursor would *stick* between browser panes if your timing was *just* right.

Which high priority task are you referring to? I think we might want to 
fix that, it seems completely pointless to run a loop like that.

> It would appear that all that code was refactored in the last 5 years. Still if you feel that looking at the mouse position 100,000 a second is worthwhile?

If I am trying to run a benchmark? Yes, absolutely.

> you could rip it all out and hope there aren't side-effects.  Like someone launch a process, then peek for mouse up. Wonder who will get the CPU? The task doing the work? Or the hyper processing spin 100,000 peeks a second waiting for the mouse to go up?

Good question. The usage of Sensor in Morphic is completely abusive. 
Sensor isn't a Morphic entity; only the hand should be used to query 
such information. I'll check it out.

Cheers,
   - Andreas

>
>
> "Change Set:		EventSensorDelayOnHyperPolling
> Date:			7 November 2005
> Author:			johnmci at smalltalkconsulting.com
>
> Attempt to ensure polling for event data does not drive cpu to 100%. Wait 2ms between looks at mouse position or for keyboard events. Usually these don't happen 100's of times per second anyways"!
>
>
>
>
> On 2010-03-23, at 9:16 AM, Igor Stasenko wrote:
>
>> On 23 March 2010 18:10, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>> On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
>>>>
>>>> Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
>>>
>>> Yeah, I was wondering why it's so much slower in trunk than in our internal
>>> images or Croquet. First I thought it's the JIT but then I looked at a
>>> profile and found EventSensor>>wait2ms called from several places in
>>> EventSensor and indirectly via Sensor anyButtonPressed .
>>>
>>> WTF? This isn't in any of the images I've ever used, does someone know why
>>> we're doing this? Randomly waiting for 2ms and *no comment* as to what the
>>> purpose of that wait might be? I'm in favor of ripping this out; there
>>> should be absolutely no need to wait for 2ms in EventSensor.
>>>
>>
>> All senders of wait2ms seems having same author , and very small time frame:
>> JMM 11/7/2005 14:39
>>
>> So, i suppose we could ask the author to comment this.
>>
>>> Cheers,
>>>   - Andreas
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
> --
> ===========================================================================
> John M. McIntosh<johnmci at smalltalkconsulting.com>    Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>
>
>