[BUG][FIX] - System window resize pane goes to CPU 100%

John M McIntosh johnmci at smalltalkconsulting.com
Wed Oct 22 01:22:50 UTC 2003


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
======================================================================== 
=== 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SlowResizeCPU-JMM.2.cs.gz
Type: application/x-gzip
Size: 1333 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031021/cbb0464b/SlowResizeCPU-JMM.2.cs.bin


More information about the Squeak-dev mailing list