>The primary problem is with resizing the world.  First of all, screen
>redraw seems to be very slow and "uncertain", this is even noticeable on
>a ~1.5GHZ system.  More importantly, resizing very often leads to a
>crash:
>
Segmentation fault


Mmmm here is perhaps a clue. When I was implementing carbon events I 
noticed an interesting flash of bits on the screen when resizing. 
Careful looking pointed to this problem.

On a resize we did a force to display call using the new window 
boundaries. However it would appear that in doing this we actually 
attempt to use bits that aren't ours because the Squeak screen isn't 
the correct size yet. This autosizing is done in

DisplayScreen class>> checkForNewScreenSize
	"Check whether the screen size has changed and if so take 
appropriate actions"

	Display extent = DisplayScreen actualScreenSize ifTrue: [^ self].
	DisplayScreen startUp.

...


Where startUp then actually allocates the bits for the new screen 
size. Therefore I'd suggest you look at the execution path and see if 
an display is being triggered with new boundaries before the 
checkForNewScreenSize can actually build the proper amount of bits.
-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================