Future of the animation feature

[Boudewijn Rempt]

Hi Jouni,

I really like the basic design you put down here, but what with the 2.9 release, I just haven't had time to really dig in. In principle, I agree with the approach, but I would like to first do a kind of ui/funcitonality mockup. I.e., figure out of each layer type what should be animatable, and have some sort of idea of the gui we want to implement, before we actually start hacking.

On the other hand, some exploratory hacking cannot hurt...

On Saturday 10 January 2015 Jan 19:49:43 Jouni Pentikäinen wrote:
> 
> Based on the discussion so far, I suggest we try the approach of adding 
> time to KisImage.
> 
> I propose the following changes (grouped by class). A UML overview of 
> these changes is available at https://creately.com/diagram/i3zzekbz1
> 
> KisImage
> - Add field for current frame
> - Add method to change current frame. This will call a similar method
>    in the root node of the document.
> 
> KisNode
> - Add field for keyframes (KisKeyFrameSequence)
>    - This contains the keyframed data associated with the layer
> - Add method to change current frame. This should recurse into all
>    child nodes.
> - Add method for creating a new keyframe at current frame. This will
>    call writeKeyframe() to get the keyframe data
> - Add virtual methods writeKeyframe and loadKeyframe to get and set
>    data associated with keyframes. These will be implemented in the
>    layer classes to provide and use parameters approriate for the given
>    layer type.
> 
> KisKeyFrameSequence (new class)
> - Contains a sequence of keyframes (KisKeyframe)
> 
> KisKeyframe (new class)
> - Contains the data associated with a keyframe
> - Data is arbitrary, as provided by the node. It is stored in a
>    KisPropertiesConfiguration.
> - For each property, there is also an associated interpolation mode.
>    This can be used for defining interpolations of continuous functions
>    such as layer opacity.
> 
> KisPaintDevice
> - Add method to switch content, requesting the data from KisFrameCache
> 
> KisFrameCache (new class)
> - Provides methods for loading raster data (e.g. content of a
>    KisPaintLayer)
> - Maintains a cache of recently used raster data
> 
> KisLayer
> - Keyframe data:
>    - Position
>    - Opacity
> 
> KisFileLayer
> - Keyframe data:
>    - filename (for image sequences)
> 
> KisPaintLayer
> - Keyframe data:
>    - Raster content (trough paintDevice)
> 
> KisAdjustmentLayer
> - Keyframe data:
>    - Filter configuration
> 
> KisGeneratorLayer
> - Keyframe data:
>    - Filter configuration
> 
> KisMask
> - Keyframe data:
>    - Raster content (akin to KisPaintLayer)
> 
> KisFilterMask
> - Keyframe data:
>    - Filter configuration
> 
> KisTransformMask
> - Keyframe data:
>    - Transform parameters
> 
> KisAnimationDoc
> - Refactor playback into UI code
> - Refactor onion skinning into projection code (?)
> 
> KisAnimation, KisAnimationStore, KisKranimSaver, KisKranimLoader
> - No longer needed
> 
> 
> As a sidenode, not all of these changes need to be done at once. As long 
> as the basic keyframing system is in place, any layer type which doesn't 
> implement keyframes will behave as a static content. "Bells and 
> whistles" such as adjustable interpolation curves can be added later as 
> time allows.
> 
> The question of file format is still open. A fairly straightforward 
> approach would be to serialize keyframes from each KisKeyFrameSequence 
> and place them either in a separate entry inside the .kra document (e.g. 
> keyframes.xml) or as a series of child nodes for each layer in maindoc.xml.
> 
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org