[BUG][FIX] - System window resize pane goes to CPU 100% ([er][et] [approved])

Doug Way dway at riskmetrics.com
Wed Oct 29 20:31:08 UTC 2003


Approved.

On Tuesday, October 21, 2003, at 09:22 PM, John M McIntosh wrote:

> Some of you might recall my complaints earlier in the summer that the  
> CPU would peg and
> perhaps the cursor would lockup when moving between panes in the  
> browser window.
> "BUG][FIX] interrupt driven EventSensor"
>
> In fact some poor Windows (TM) users complained to me that it could  
> bury the meter and they would need
> to force quit squeak because it became useless.
>
> My solution if you recall was to meter access to EvenSensor's cursor  
> data, but that was deemed unacceptable as compared to hunting down and  
> killing the real issue.
>
> Thus I've done that.
>
> It seems there are two factors in play here
>
> a)SystemWindow>>spawnPaneFrameHandle:  (and others) create an instance  
> of NewHandleMorph which
> is responsible for managing the cursor and changing it to a resize  
> cursor. It checks to see if the cursor has
> moved outside the area of interest, say the 2 or 3 pixel boundary  
> between panes. The issue is it's inherited
> step time is zero, thus it spins the CPU to 100% as it waits for the  
> cursor to move outside it's area of play.
>
> I decided to change HandleMorph stepTime from 0 to 10 milliseconds.  
> Note sure if this is the correct decision since
> HandleMorph is a superclass and used for other things, but if you  
> consider that means about 100 mouse looks a second this might be  
> acceptable. On the mac I think we see about a change every 16  
> miliseconds. Anyways others can look to see what the effect is.
>
> That didn't solve everything, it seems we bury the CPU when we click  
> and do the resize so lets go look. Ah, were does that
> logic come from, ah yes:
>
> b) Rectangle>>newRectButtonPressedDo:  & Rectangle>>newRectFrom:
>
> Well I'm not going to argue if that logic should exist in Retangle, or  
> how to change it to use events properly. However inserting a delay  
> forMilliseconds: 10 in the while loop prevents the CPU from going to  
> 100%. Now I noticed the usage of "Processor yield" which I followed as  
> perhaps a pattern usage clue by the original author and found, yes it  
> was used only in one other place of interest.
>
>
> c) View>>stretchFrame:startingWith:
> ??! I don't have a test case for this, but the pattern is the same,  
> Looking at all three I think you could argue for consolidation.  
> Perhaps someone would like to refactor this?  And come up with a test  
> case for this method?
>
> --
> ======================================================================= 
> ====
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================= 
> ====
> <SlowResizeCPU-JMM.2.cs.gz>




More information about the Squeak-dev mailing list