Color and Gradient animations

[Jim Graham]

One "new overhead" issue to consider - if you create non-mutable paint 
instances and set them into Shape objects directly and then expect a 
repaint whenever those mutable paints mutate then there will have to be 
some sort of new listener created to manage that.  If the implementation 
is too basic (assuming all Paint objects could be mutable) then we end 
up with listeners for all paint objects even if they are immutable.  If 
the implementation is at least smart enough to recognize the mutable 
objects then we still have listeners for those objects and there is 
still some turmoil when they animate or change - thus negating much of 
the benefit over just having the external animation object set a new 
immutable paint object.

Binding the Shape paint properties to a mutating value property involves 
the least overhead on the part of the Shape node I think...?

			...jim

On 4/16/2012 7:17 AM, Martin Sladecek wrote:
> 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