Dear Eddie,

> Some of us on the Squeak IRC channel (#squeak/openprojects.net) 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).

4 seconds?! That's a lot of dragging!

> 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).
[snip]
> 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.

Hmmm. What about creating a MutableRectangle subclass? Not that you
haven't thought of that, but why not? It would be available for those
Morphs that need it, and would not bother those that do not use it. (I
don't know other alterations would be required to make that option
available.)

> 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.

Well, since the dragging is smooth, even with Minesweeper, which has a
*lot* of rectangles, and will not be dragged much in use, is dragging
really a problem? Animation is another question. How complex are
animated morphs? Has the problem shown up in animation? 

Best,

Bill