Mutable Points/Rects in Morphic

Eddie Cottongim cottonsqueak at
Sat Feb 15 07:06:34 UTC 2003

Some of us on the Squeak IRC channel (#squeak/ were looking
at some ill behavior in Morphic. When you drag a complex morph (say for
example a Mines game) the dragging is smooth, but about every 4 seconds,
there is a one second pause (this is on my machine). I am 90% sure the pause
is caused by full GCs, provoked by excessive object creation during the

As you drag a Morph, the Morph and all its submorphs are sent #position: and
further down in the chain, #privateMoveBy, and then Rectangle>>translateBy:.
The problem is that translateBy: in particular creates lots of new Points
and Rectangles with a very short lifespan: About 4 Points per morph/frame,
and a total of over 80,000 objects/second on my machine. No wonder the GC
fires up a lot. (This occurs in a few other situations but dragging is the
most obvious).

Brian Rice's ENH to Rectangle>>merging helps in some other situations, but
this Rectangle>>translateBy: problem remains, and its not easily fixed.
Rectangle>>translateBy: is responsible for the vast majority of the
short-lived objects.

Rectangles and Points are currently non-mutable. They can be forcibly
changed through abuse, but a lot of code assumes they are non-mutable and
will break if they are altered.  A quick hack to translateBy eliminated the
GC pauses, but of course is not safe, and caused all sorts of problems with
code relying on the non-mutability.

I'm not sure where to go from here. We looked at several options for getting
around this, but none look very feasible to me right now. Any ideas? I can't
think of anything that would have any actual chance of being adopted. I
don't think ignoring the problem is a very good way to go; games for example
really can't tolerate that kind of behavior. And conceptually, creating
80,000 garbage objects/second just because I want to drag my minefield isn't


More information about the Squeak-dev mailing list