Re: TimingFramework triggers for Trident - Let's try again

[Kirill Grouchnikov <kirillcool@yahoo.com>]

Thanks for the lengthy explanation. Would the following capability work for you?

* Adding Timeline.playFrom(int milliseconds) and Timeline.playReverseFrom(int milliseconds)
* Ignoring the initial delay
* Still firing the relevant timeline events, but the first READY -> PLAYING will start at the matching duration / fraction

There are two other things that you mentioned:

Application control over the timeline engine heartbeat. This is good for at least three purposes:

1. Plugging in a more fine grained (perhaps natively driven) timer.
2. Supporting the testing of the timeline engine.
3. Supporting custom playback of timelines in the designer tools.

I'm not sure that this will be a part of the first release.

The second thing is about the Swing-specific stuff and extensions. Depending on the resources i'll have in the next few weeks, here is what i would like to try:

Create an extension mechanism that will allow different UI toolkits to plug in the specific threading rules / behavior. This will include:
* TimelineScenarioActor implementations specific to that toolkit
* Honoring the threading rules of the specific UI toolkit with the core @RunOnUIThread annotation

The implementation is still in my head, but i see this:

* Trident core supporting Swing and SWT out of the box - as blueprint implementations of supporting UI toolkits.
* When the timeline is created, each UI module is asked whether the timeline main object is "known" to that module.
* If so, the UI module will be asked for special treatment of the property interpolation / callback invocation. In Swing, that would be with SwingUtilities.invokeLater. In SWT, that would be with Display.asyncExec
* Swing module will provide the TimelineSwingWorker. SWT module might provide task-based actors - not sure about this still.

Then, additional Java based UI toolkits such as Pivot and Qt-Jambi can play nicely with the Trident core without the Trident core being explicitly aware of them.

As to the extensions - honestly i still don't have a final answer on whether i would like to see the Swing / SWT specific triggers in the core library.

Thanks
Kirill

---

From: Rémy Rakic <remy.rakic@gmail.com>
To: dev@trident.kenai.com
Sent: Thursday, May 21, 2009 12:03:23 AM
Subject: Re: TimingFramework triggers for Trident - Let's try again

Thanks for the answers Kirill.

I do have a use case for setting the timeline at a specific position: visual tools :) (And more generally, just testing the animations look good)

Let's say i have an animation that lasts X seconds, and the second half looks bad, if i modify its code Y times to get it right, and have to watch it from the beginning everytime while testing - even though i only want to check the second half - i've probably wasted close to xy/2 seconds of my life ;)

That's the basic idea, but i'll explain why it would be interesting in the current situation.

Amongst the 250 projects i'm doing at the same time, i have a mini editor in the works, that lets you visually modify a scenario timeline (their timeline contains animations and timelines, so it's more like your timeline scenarios). Currently it only lets you modify the length and offset of an animation, and i plan to add minimal value editing later to make it more useful.

In my particular workflow i find animations even harder to get right than graphics, because there are so little visual tools for animation (like flash and _expression_ and that's maybe it). Since i do most of my mockups in a visual tool, this is where i usually get the correct start and to values for the animations, however duration, sequencing, easing, transitions and so on obviously has to be done in code at the moment. This is terrible and takes a huge amount of time, so this mini editor is supposed to help reduce the feedback loop here, for a more streamlined workflow.

(The ability to have a good visual tool is so valuable to me that i've been praying for the nimbus designer code every night before i go to sleep, that's also why it won't matter how complicated or weird it is, i will have to use it to offer a good workflow)

The tool is generic enough and now that the scenario model is finished, the plan was to add support for trident, (and maybe the animationframework too, but it's doubtful). It is generally a requirement in any tool that deals with time to have a scrubbable timeline or see what your animation looks at a specific time in general: to make sure the values are correct and everything looks good, or not, and keep editing. So at the moment, i design the regular ui, and the finished state of the animations, and then jump to my IDE, and create the animations in code using those latter values. Once i've done that, i need to test them, and it's more or less like this (hopefully i've made the next sentence as hard to experience reading as i lived it a little while ago): modify code, launch, wait and watch, hum what ? relaunch it, that's weird, start the anim again from 300 ms, hum, this seems a little weird here, pause, move the timeline head to a position to see where the glitch is, oh there's a bug in my code shape interpolation code, moving on, relaunch again from after the faulty middle animation, looks kinda nice, but no that's not it the 3r anim in the sequence needs to be maybe longer, modify code, launch, wait and watch, nope too short again, and so on until what, a week later when and i'm finally satisfied with this 300ms animation.

With this little tool, the sequencing and duration is much faster, it'll be even better when i get to edit values and keyframes but i haven't had the time to get to it just yet. So, in order to check the animation start and to values are all good, every keyframe is good, and so are the interpolated frames, the duration of subanimations and their sequencing, it's usually easier to be able to start a specific position, (and scrub the timeline too, thanks to it), it's a way to control the time factor, you can use it to manually slow down a part of an animation, check specific time values and so on. I, personally, don't really know any other way in the limited knowledge i have of the tools that support animations, be it the ones we mentioned or video editing and visual effects, and IIRC the animations modules of some 3D modeling tools too.

I think all the other features needed in a visual tool are pretty much already done in trident, except for this one.

This is the use case, but you're spoiling the surprise :)

As for the triggers, do you plan on creating this "trident extensions" project ? maybe i'll change the package, and offer them on my blog in the meantime. They could be interesting for some people, maybe at least to our groovy friends :)

Thanks
Rémy

god, i've reread this email, it's awfully long !

Kirill Grouchnikov wrote:

Hi Remy

Thanks for starting the conversation about the triggers. In general, i do want Trident to be a general purpose animation library for Swing applications. At the present moment, all Trident demos are Swing apps, since it's most comfortable to me, produces nice videos and is, frankly, a good match for the animation domain in general. There are quite certainly a few Trident built-in features that target Swing - support for SwingWorkers in scenarios and running stuff on EDT.

However, as a long term plan i do want to refactor the Swing-specific functionality to a separate add-on library. Then, a similar library will be created for SWT, and both will serve as sample add-ons for additional interested Java-based UI toolkits (Pivot, perhaps).

As such, i would rather not fold the Swing triggers into the core library now, but suggest opening a new project and maintaining it until the rest of Swing-specific code in Trident is moved there.

To your other questions - yes, the timeline state is changed asynchronously in the main timeline engine thread. This is by design, and there are still a few issues there that need to be addressed - but in general you shouldn't expect the state to change immediately after calling the relevant Timeline / TimelineScenario APIs. Specifically in your test code, you potentially have a lot of timelines all competing over the same property of the same object - and not starting from the current value as it is at the point when the trigger is activated (but rather start from the current value at the point the timeline was created).

And i don't have immediate plans to allow playing a timeline from the specific position - unless i see a clear need from a real scenario.

Thanks
Kirill