Color and Gradient animations

[Martin Sladecek]

Hi,
the current API uses StrokeTransition and FillTransition to animate 
color and you need to create custom Transition in order to animate 
gradients. Both ways do not perform well as Color and gradients are 
immutable, so new objects need to be created every pulse during the 
animation.

Here are my proposals to solve this:

1) As Color, LinearGradient, etc... are immutable, we cannot just make 
them mutable without braking backward-compatibility, so we could have 
new Animated* (AnimatedColor, AnimatedStop, ...) classes, that would be 
mutually convertible with their immutable counterparts. The downside is 
that there would be a lot of duplicated code.

Example usage:
AnimatedColor color = new AnimatedColor(1.0, 0, 0);
shape.setFill(color);
//Timeline manipulating "red" property

Also FillTransition and StrokeTransition can internally used this, 
although they would be limited to (Animated)Color.

2) Merge FillTransition and StrokeTransiton into ColorTransition 
(accepting ObjectProperty<Paint> instead of Shape, although this is a 
bit different pattern to the other Transition classes) + introduce 
LinearGradientTransition and RadialGradientTransiton.
The transition would then handle the mutations internally, although this 
probably means we need special implementations of ObjectProperty<Paint> 
in all affected objects.
*GradientTransition objects would be tricky however. It's hard (if 
impossible) to define any reasonable and generic interpolation between 
two arbitrary gradients, so everything would need to be configured by 
calling methods on the transition objects.

3) Have some ColorModifier/*GradientModifier classes, that would expose 
Color/*Gradient properties as FX properties, so they can be animated by 
normal timelines. Shape's fill and stroke properties would then bind to 
one property of these modifiers.

ColorModifier cm = new ColorModifier(1.0, 0, 0);
E.g. shape.fillProperty().bind(cm.result());
//Timeline manipulating some cm property

Again, this means we need special implementations of 
ObjectProperty<Paint> on Shape's properties in order this to work 
efficiently.

What do you think? Any other ideas?

-Martin