Presumably, even if your morphs are less complex, you'll get the same GC
freezing, just left often. I decided to try this out, and its not true.

A mine game of 15x10 (150 tiles) or more will exibit the freezing problem.

A mine game of 15x9 (135 tiles) or less does not exibit the freezing
problem.

I don't claim to be a GC expert, but my guess is that the incremental GCs
are able to keep up with the garbage production up to some threshold. Past
that, occasional full GCs are needed to catch up.

So maybe if this is a problem for your application, you can make the
incremental GCer a bit more aggressive? That would sweep the problem under
the rug, for now. I still think the way we are using rectangles and points
isn't very efficient, with around 40% of the time while dragging spent
creating points and rectangles. But it has been good enough up to now, and
no one else is complaining much.

Eddie

----- Original Message -----
From: "Ned Konz" <ned at bike-nomad.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, February 15, 2003 3:55 AM
Subject: Re: Mutable Points/Rects in Morphic


> On Friday 14 February 2003 11:06 pm, Eddie Cottongim wrote:
> > 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.
>
> On the other hand, how often are you translating such complex morphs
> manually? Would a game have a complex Morph moving all the time?
>
> If you have a large moving object, it would work much better if it
> wasn't extremely complex.
>
> --
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>
>