[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Dirty hack
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Dirty hack
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Fri, 15 Sep 2000 12:55:41 +0300 (EETDST)
- Cc: Tuomas Lukka <lukka@xxxxxxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <39BFBF4E.BDACE674@xxxxxx>
> >From a different eMail:
> > One more thing about the interpolation stuff: one thing we want eventually
> > is to be able to interpolate between permascroll spans that are referenced
> > through different cells.
> >
> > So that we can first see one text stream on display and then switch to
> > another one and see the cut&pasted pieces of text morph. This would be a
> > great demonstration of something you can't do without permascrolls.
> >
> > This doesn't fit the current nor the proposed framework well because both
> > are based on cells. But this may be common: we may want to identify bits
> > and pieces on the screen by other things than their cells.
> >
> > The big question is designing a fast enough system that still allows that.
>
> Hm... couldn't we for the moment stick to spans and cells? We could also
> add a flob type, so that only flobs of the same type would be
> interpolated to each other. If we *do* want to interpolate between two
> different flob types, we can have special-case interpolation methods;
> so, a flob would have:
> - a flob type, as a pointer (probably to a class?), not a string, so
> that comparison is fast, and
Is this like the flobPath or the simply the type of the object?
> - two arrays of flob types it can interpolate from and to (excluding its
> own flob type, which it *must* be able to interpolate to).
This could possibly make sense.
> That seems to make sense because an interpolation between two totally
> different flobs ususally won't look very good if the flobs assume
> they're interpolating to a flob of the same kind. A usage which comes to
> mind is morphing a rectangle meeting type flob from the daytime demo to
> the colored background area denoting the meeting in the daytime raster.
> Standard interpolation wouldn't look very good, but we *could* change
> the shape and color gradually.
Actually, that application would still benefit greatly from the
interpolation since that would show which pieces of information are the
same. The point of interpolating is to show "this is that", and it doesn't
always need to be the most beautiful. The human eye can cover many of the
more difficult cases for us ;)
Tuomas