Color and Gradient animations

Jeff Martin jeff at reportmill.com
Mon Apr 16 08:01:46 PDT 2012


I'd be surprised if creating new Paint objects was a significant overhead compared to a scene repaint. Have you done a measurement?

Jeff Martin


On Apr 16, 2012, at 9: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



More information about the openjfx-dev mailing list