Re: [zzdev] Re: [zzdev] Dirty hack

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> > When we
> > render the cells' contents as SplitCellFlobs, these are *children* of
> > the cell background flobs (necessarily, as there may be multiple
> > SplitCellFlobs -- for multiline -- but only one background flob). If we
> > then interpolate between a cell view and a text view (e.g. vstream or
> > prez), the empty bg flob is interpolated to the text -- like it's now.
> 
> Excellent case. So in that case, the background *AND* the splitcellflobs
> should interpolate to the full flob.
>
> But text splitting in the normal cell is not easy to handle.
> 
> Maybe we should do text and graphics separately: interpolate spans to
> spans? But that would be slow.

Let's look at it this way: when the cell flob can be interpolated to
another cell flob, it should be. If the cell flob is interpolated, it's
'contents' -- i.e., the text flob -- should be interpolated to the text
'contents' of the cell flob interpolated to.

If the cell flob cannot be interpolated to another cell flob, but the
text flob can be interpolated to another text flob, then the text flobs
should be interpolated, and the cell flob should just vanish (like every
flob for which there is no interpolation target).

At least that makes most sense to me.

> So one problem is that interpolation needs to be possible both ways.
> 
> > That's not going to work. We *do* want to interpolate the text, and
> > similarily we might want to have special-case interpolation behaviors
> > elsewhere. Actually I think we should go for the FlobSet-is-a-Flob
> > thing, but we shouldn't lock ourselves up to a hierarchy; there should
> > be interfaces to use different structures when necessary. I just don't
> > know yet which.
> 
> Hmm, the question is, I guess, what the general cellflob needs to know.
> 
> An interface which would allow one flob to say essentially
> "Trust me, I know what I'm doing" ;)
> could be a pretty good thing.

*nod* Hmm... this requires a call into the flob saying "please search
for an interpolation target you like," right? Wouldn't that be slow?

> Basically, a single cell can be
>         - all at one place
>         - shown in several places, with continuous rasters
>         - split into parts
>         - shown in several places, some split into parts
> 
> What comes to mind is that if the cell is split, then all the pieces
> of the *same* split individual should animate to the same place.

Absolutely right. Maybe we should make it possible for a number of flobs
to act like an "entity," basicly like the SpanFlobs do now? Then, these
would *only* be interpolated together; and for rendering an
interpolation of the whole entity, only one routine would be called.

This would work only if they would be interpolated to another entity of
the same type (class). When interpolating between different types, we
could require them to "flow together" to form a rectangle; then, the
flob we interpolate to would start its interpolation from that rectangle.

> Here, the case would be the single cell split into parts, and all parts
> should interpolate to the same destination. The problem there is that
> if the destination is a single cell, then actually we should plot
> the split flobs for the complete duration of the interpolation...
> 
> We need an API for coordinates of a particular piece of stuff...
> 
> Very hard to do well generally.
> 
> > Hm, generally what about an interface to iterate over all children flobs
> > of a flob set, direct *and indirect*? And then in the FIRST round
> > selecting flobs for interpolation hierarchically, and in a SECOND round,
> > iterating only over flobs which don't have an interpolation associated
> > yet, interpolating flobs which cannot be interpolated otherwise.
> > Possible algorithm would be a callback structure (like DepthIter), and
> > then doing a recursive call to the flob sets which is handed the
> > callback object. (Am I making sense?)
> 
> This doesn't help when you want one to many and many to one splitting.

I'm not following. What is many to one splitting?

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

Basicly the type of the object; however, if we have an inheritance
structure like Renderable -> Flob -> SplitCellFlob1 -> MyTextFlob, the
flob type is supposed to be SplitCellFlob1, so that MyTextFlob's can be
interpolated from and to SplitCellFlob1's.

-b.