[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Dirty hack
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Dirty hack
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sat, 9 Sep 2000 18:41:53 +0300 (EETDST)
- Cc: ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <39BA3724.CCA07B65@xxxxxx>
> just put in a DIRTY hack to make flob interpolation right. Dirty because
> it masks the new behavior in the old interface (so that I don't need to
> change everything that calls findFlob()), and because it just goes
> through the flobs five times to find the best way to interpolate.
> (Doesn't *always* find the best way, I think, but usually.) Hope to
> clean it up soon.
Umm, why not use the parent cell's ID as the flobpath? We don't want to
waste space for *both* a flobpath and a parent cell. Another way is of
course to get rid of flobpaths. I don't know.
Now, the big question is: how much hit to performance is this when the
features are not used? How efficient can it be made? The point is that we
want to be able to slap thousands of flobs to the screen quickly and
interpolate between them.
At one point I had planned to make FlobSets hierarchical so that a FlobSet
is also a Flob that can be painted on the screen. It might be faster that
> Anyway, pls have a look at it and tell me if you think the structure is
> reasonable (flobs can have parents, and interpolation is to nearest flob
> with "same" parent, where "same" means: the first flob's parent is
> interpolated to the second flob's parent).
This sounds reasonable.
Combining this with some way of showing beams, i.e. showing that two flobs
are in fact from the same cell would be interesting.