Re: Possible limitations with Trident's implementation

  • From: Burt Alexander <burt.alexander@gmail.com>
  • To: dev@trident.kenai.com
  • Subject: Re: Possible limitations with Trident's implementation
  • Date: Fri, 17 Jul 2009 18:16:28 +1000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=mNZKU/STbT6D9qRQmoDLjhqMi1yMl3wnuRfAk4DoDWO2IPizZeJxqS2nhMRZymj0Ax K0Q5GmU+cC2b42BwG/C7KiYx9Bqrx0H2fWxfXJvRe8J7uPsXz/kuYiQdtNFOc0ygxvcU PZhihmvE00W7yLLYI7IxIWosa5uR0sF1wtZZ8=

Thanks Kirill, for simple animations I can certainly see an advantage.  I do however see two issues with the KeyTimes/KeyValues.  The first you mention - its not terribly pretty to scale & could lead to some quite unreadable code, but can be mitigated with a helper method or utility.  The second is a limitation of this approach in scenarios.  If one were to have multiple animations running on an object (as I do with my testbed class) it is impossible to know, in this example, the exact position of the floating ball ahead of execution time.  The 'addPropertyToInterpolateTo' method of Timeline caters for this, however KeyTimes/KeyValues are not catered for in this manner and as such it would not be possible to chain them for smooth transitions between timelines.  With enough mix & match & clever implementation I'm sure it would be possible to circumvent if required, but then there's the readability to consider...

While I've not fully implemented (or fully tested!) TimelineChain to behave as your full-featured Scenario class, it does give me a consistent API with which to work, and lends itself to quite readable & maintainable code.  For instance, this is the code to bounce the ball to a standstill:


    private TimelineChain getFarPositionTimeline() {
        TimelineChain chain = new TimelineChain(schwartzBall);

        double height = schwartzBall.getY();

        TimelineEase ease = new Sine();

        chain.addTimeline(500, ease);
        chain.addTransition("y", getPreferredSize().getHeight() - 50);

        height = height / 0.9;
        while (height < getPreferredSize().height - 50) {
            chain.addTimeline(500, ease, RepeatBehavior.REVERSE, 1);
            chain.addTransition("y", height);
            height = height / 0.9;
        }

        return chain;
    }

Not a physics engine, but it is a reasonable approximation.  And the implementation is consistently similar with the code to flash the splash screen and is easily readable.

"It indeed can only play the added timelines forward - no skipping, no backward, no looping"...and no explicit repeating of individual timelines (something else that testbed class of mine requires).  Certainly, I believe this type of functionality would be very useful in TimelineScenario.  As a developer I would wish to use the classes as follows:

1. Create each Timeline with its behaviour defined ahead of execution time, either externally to TimelineScenario or thru helper methods a la TimelineChain.  With no restrictions on behaviour!
2. Add them in order I wish to see them executed to a TimelineScenario instance.
3. Play the scenario when appropriate in the code.

Number 1 is really the only sticky point; the rest are already there.

Nice to haves:

1. Ability to reset the scenario (automatically after playing - state for the scenario prior to execution).
2. Ability to play the scenario in reverse

A possible starting point could be making TimelineScenario a TimelineScenarioActor?

Anyways, as I mentioned I've got my solution!  Hope my perspective has been of assistance.  Thanks again.


          Burton.


Kirill Grouchnikov wrote:
861295.11580.qm@web110814.mail.gq1.yahoo.com" type="cite">
Hi Burt

Before getting into the full functionality of your StatefulTimeline and TimelineChain, i would say that the specific scenario is perhaps better addressed with key frames [1]?

Something like this:

KeyValues values = KeyValues.create(BACKGROUND, ANIM, BACKGROUND, ANIM,
    BACKGROUND, ANIM, BACKGROUND);
KeyTimes times = new KeyTimes(0.0f, 0.05f, 0.1f, 0.15f, 0.2f, 0.25f, 1.0f);
timeline.addPropertyToInterpolate("background", new KeyFrames(values, times));

It might become a little awkward for bigger loop count, but then you can create a helper method to initialize the KeyValues and KeyTimes accordingly.

From your implementation of the TimelineChain it does look like you are not satisfied with what timeline scenario [2] provides. It indeed can only play the added timelines forward - no skipping, no backward, no looping. Is this something that you would like to see added to the TimelineScenario?

Thanks
Kirill

[1] http://kenai.com/projects/trident/pages/KeyFrameOverview
[2] http://kenai.com/projects/trident/pages/TimelineScenarioIntroduction


From: Burt Alexander <burt.alexander@gmail.com>
To: dev@trident.kenai.com
Sent: Thursday, July 16, 2009 2:24:09 AM
Subject: Possible limitations with Trident's implementation

Hi Kirill, I'm moving this discussion to the dev mailing list as requested.  And as the title of this email suggests, the limitations may very well lie with my current understanding of Trident.

Out of the box, Trident didn't work (wrt its usage) as I expected it to work; as I mentioned I could not work out how to chain Timelines together in the manner I wished.  As I also mentioned I've come up with a solution for this (and based on our discussion & the thinking it triggered, I've improved upon it; pls look at the latest version of TimelineChain and my subclass of Timeline - StatefulTimeline - within my Java 5/Swing version of your 1.0 release, for the details).

The simplest use I make of TimelineChain is in my startup splash screen.  With the animation I wish to transition between two colours quickly for a couple of times, then return to the original colour much more slowly.  Here's how I accomplish this with TimelineChain:


    private void animateBackground() {
        chain = new TimelineChain(getContentPane());

        // Play from the original colour to another,
        // looping twice.
        chain.addTimeline(200, null, RepeatBehavior.REVERSE, 2);
        chain.addTransition("background", ANIM);

        // Play to the second colour as quickly
        chain.addTimeline(200);
        chain.addTransition("background", ANIM);

        // Slowly return to the original colour
        chain.addTimeline(2000);
        chain.addTransition("background", BACKGROUND);

        chain.play();
    }

TimelineChain only ever calls the 'play()' method on Timeline.  Using StatefulTimeline I am able to construct a Timeline object that determines which of its 'play' methods to invoke based upon its state, upon execution of its 'play()' method.

How would you recommend I accomplish the same functionality using just the Trident classes?

I'm unsure what you meant when you said "I'm not quite comfortable with exposing this functionality to the application".  StatefulTimeline does not expose anything which isn't already exposed, rather it provides the ability to define repeat behaviour, loop counts and skips prior to the invoking of 'play()' - which is how I'd expect to use it.

I am getting long in the tooth; perhaps I'm just set in my ways ;>)  Thank you for your time & thanks again for the library.


       Burton.




Possible limitations with Trident's implementation

Burt Alexander 07/16/2009

Re: Possible limitations with Trident's implementation

Kirill Grouchnikov 07/16/2009

Re: Possible limitations with Trident's implementation

Burt Alexander 07/17/2009
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2010, Oracle Corporation and/or its affiliates
(revision 20120127.ac94057)
 
 
Close
loading
Please Confirm
Close