[Fenfire-dev] Re: [Fencommits] libvob: steps towards a slightly new interpolation system, where cs without keys are shown during interpolation

[Benja Fallenstein]

Hups, I forgot about this mail. :-/

On Wed, 26 Jan 2005 17:42:01 +0200 (EET), Matti Katila
<address@hidden> wrote:
> On Sat, 4 Dec 2004, Benja Fallenstein wrote:

Hmm, at least I didn't take longer to reply to your mail than you took
to reply to my commit ;-)

> > Sat Nov 27 00:16:11 EET 2004  Benja Fallenstein <address@hidden>
> >   * steps towards a slightly new interpolation system, where cs without 
> > keys are shown during interpolation
> >
> > +    public static class DoNotInterpolateException extends RuntimeException 
> > {
> > +     public DoNotInterpolateException(String s) { super(s); }
> > +     public DoNotInterpolateException() { super(); }
> > +    }
> 
> Please, document this new parameter. I didn't get the idea behind it.

Not necessary, it vanished in the meantime =-)

Well, if you're interested, let's say a cs is specified as
SHOW_IN_INTERP in the interpList, which means that it isn't
interpolated but shown during the interpolation. But let's say that
some parent of it is not interpolated; then the child should also not
be interpolated. The point is that we can use SHOW_IN_INTERP for e.g.
the contents of a node; if the node is interpolated, the contents go
with it, if the node isn't interpolated, the contents aren't shown,
either.

So if you called transformRect(), and one of the cs's ancestors would
be specified as DONT_INTERP, then a DoNotInterpolateException would be
raised.

> > -    protected void getAbsoluteRect(int cs, float[] into, float[] scale) {
> > +    protected void getAbsoluteRect(int cs, float[] into, float[] scale,
> > +                                boolean useInterp) {
> 
> If I got the basic consept, vobs without a key are rendered while
> animating, right? So why we need exceptions? This is innerloop and
> exceptions are a bit slow in jawa.

You're right. It actually did become a problem last weekend, which
IIRC now was the motivation for the Coordinates caching stuff [which I
hope you don't dislike so much now that it does recursive vobscenes
and cs parameter setting correctly ;-)]. The behavior is the same as
before, but it's implemented without exceptions.

(BTW, for the Education of the Lurkers :) -- Java exceptions are slow
because they insist on 'filling in the stack trace', generating a lot
of String objects for Java to garbage collect.)

> Btw. this vob coorder looked extremely ugly - I think it's because i have
> written it.

=-}

- Benja