On 23 March 2010 19:50, John M McIntosh <johnmci at smalltalkconsulting.com> 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.
>
> 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?
> 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?

My 2c.
A tight polling loop is, obviously, a mistake, an abuse which should
be fixed in places where it is used, instead of patching the
implementor.
Because it is really ridiculous to patch the implementation to suit
the needs of bad design practices. :)
Sure, it is easier sometimes, than fixing the issue which causing it :)

>
>
> "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
> ===========================================================================
>
>
>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.