Future of the animation feature

Sun Jan 25 10:41:43 UTC 2015

Hi, Jouni!

I really like your design. Especially the way you suggest making all the
layer types configurable. Though I'd like to talk about some problems which
might arise.

1) KisNode should not switch KisPaintDeviceSP pointers. Ideally, KisNode's
*public* interface should know nothing about frames and stuff.

Why? Firstly, we store pointers to paint devices of (other) nodes in quiet
a lot of places. The best example is KisCloneLayer. Above that we have lots
of updates and strokes objects that might be queued, so their access to
"switched" nodes will have to be synchronized is some way.

Secondly, no Krita code knows about animation, so its public interfaces
should be as small as possible.

Thirdly, if we switch paint devices directly, how would we handle undo/redo?

Possible solution:

* KisImage knows about frames and has their index. This index is shared
with consumers using KisDefaultBounds interface (see how wraparound mode is
implemented and level-of-detail feature (the latter one is stored
krita-testing-kazakov branch).

* KisNode knows nothing about animation

* KisPaintLayer also knows nothing about animation

* KisPaintDevice knows about animation, can switch it's content (using
switching data managers (see krita-testing-kazakov)) and do
blending/mixing/interpolation for non-key frames (disputable). Current
frame index can be read from KisDefaultBounds provided by the image.

* Switching current frame happens in the image only and can be integrated
into undo/redo.

2) I'm not sure KisFrameCache should belong to KisImage. It fits more to
KisPaintDevice, where all the switching happens.

3) Actually, I would suggest doing this obviously huge project in iteration
approach. That is doing small parts of it sequentially. Like that:

3.1) Implement animation for *paint layers only*. Doing it using
KisImage/KisPaintDevice-only approach would take something about a month of
work and will break almost nothing in Krita. It can also be easily tested
using unittests.

3.2) Implement UI for switching frames and playing it.

// Here we might need to reserve some time for implementing a cache of
already-rendered frames to be able to play them. Straightforward approach
with rendering them on-demand most probably will be too slow.

3.3) Implement saving/loading of such layers

// at this stage we will have a deliverable product that we can even
include in Krita 3.1 or 3.2.

3.4) Port KisTransformMask to already prepared and stable animation
framework.

// at this stage people will be able to use transformations to create
animations.

3.5) Work with other types of layers.

On Sat, Jan 10, 2015 at 8:49 PM, Jouni Pentikäinen <mctyyppi42 at gmail.com>
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
>

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150125/61e735b3/attachment.html>