Original Message

From: Christopher.Oliver@Sun.COM [mailto:Christopher.Oliver@Sun.COM]
Sent: 15 May 2007 23:18
To: users@openjfx.dev.java.net
Subject: Animation [was Re: Simple example of a clock]

On May 15, 2007, at 3:07 PM, Gerardo Horvilleur wrote:

> I agree that declarative animation would be cool, but I have two
> concerns about that:
> 1. What are the limits of declarative animation?

I guess I should have been more specific: I want "unlimited"  
declarative animation. :)

There's really no point in debating this right now. We need to dive  
into specific examples. I'm not sure when I'll have time to do that,  
but feel free to identify some and start discussing them.


Types of animation operations

1. Transitions

This is what the Canvas tutorial calls animation and appears to be what the java fx syntax is designed for.

var i = [1..100] dur 1000 linear;

This works really well and is great for doing fades and other visual effects triggered from user interaction. The syntax only works for transitions that have a defined length.

2. Sleeping/waiting

This is when you don't want to perform an action until a specific timeout has occurred. This can be further extended to be conditional in that you want the timeout to be cancelled if a predicate evaluates to false, alternatively you may want to wait forever until a certain condition is met.

The demo code appears to perform this functionality in the following way:

for (i in [false, true]) (dur 500 while selectedProposal == value) {
        if (i and selectedProposal == value) {
            selectedDoc = completionProposals[value].documentation;

This appears to hack in a for loop so that you get a sleep of 500s. To me a cleaner easier to read syntax would be something similar to the following:

Wait 500; //sleeps for 500 ms
Wait 500 while selectedProposal == value; //sleeps for upto 500 ms finishing earlier if selectedProposal becomes <> value
Wait while selectedProposal == value //waits forever for selectedPropsal to become <> value

Obviously while it is waiting it doesn't block the event dispatch thread so that the user can still interact with other parts of the gui.

3. Timer based animation.

This is when you have a timer which ticks at fixed intervals and is what you want for continuous animation. The clock demo uses

attribute Timer.elapsed = bind if running then [1..20] dur 1000 linear while running continue if true else 0;

I keep rereading this and it still isn't obvious what it does or how (an essential feature and one that javaFX seems to be emphasizing with its wordy syntax). I don't get the [1..20] I can see that it is a hack to run the loop multiple times (as proved by the fact [1..1] doesn't appear to work. But 20 seems to be an arbitary value yet lower values such as 3 appear to make the clock move very jerkily which I can't explain.

The way I've been doing animation is with the following code:

import javax.swing.Timer;
import java.awt.event.ActionListener;
import java.lang.System;

class TimerModel
	attribute period: Number;
	attribute tickCount: Number;
	private attribute myTimer: Timer;

trigger on TimerModel.period[oldVal] = newValue  {
	var model = this;
	model.myTimer = new Timer(100, new ActionListener()
							operation actionPerformed(event) {
								model.tickCount ++;

This uses the swing Timer to schedule repeated events within the Event dispatch thread. Other objects bind to the tickCount and so are automatically updated when the tick occours. Other adaptation layers can easily be bound to the tickCount to perhaps return values oscillating between specific ranges, wrap, plateau at a specific value or apply other functions such as sine on top of it.

JavaFX could either implement this in a similar object based way or perhaps have syntax similar to

do every 1000 [while running==true] [with TimerModel] {

The while would be a predicate whereby the do would finish when that condition was met. The with could be used to effect the scope that the variables have, either a class - in which case the do is applied to every instance of the class like triggers, or a particular object in which case it is only applied for that particular instance. The break statement could also be used to terminate the do.


Anyway those are some initial suggestions to get the discussion started. If animation processing remains similar to events in that they run in the event dispatch thread with everything else then synchronization and deadlock issues will be no worse than dealing with events.

Community content is available under CC-BY-SA unless otherwise noted.