Future of the animation feature

[Dmitry Kazakov]

Hi, Jouni!


Nearly all animation related data and functionality is currently contained
> within a single class, KisAnimationDoc. It handles all kinds of operations
> from playback to renaming files. This needs refactoring to improve the
> separation of concerns.
>

Yeah, maintaining the code contained in a single class might be rather
complicated. More than that, right now we already have at least two
implementations of the animation :)

Before starting refactoring I would highly recommend to prepare at least a
draft of UML diagrams of what you are planning to achieve. This way the
refactoring will come faster and more successful. I usually create diagrams
using http://creately.com They allow create public diagrams and edit them
collaboratively.



> Another issue is that currently the animator effectively reimplements its
> own layer stack. I think this is unnecessary. I suggest we add a new layer
> type instead, an animated layer, which would integrate into the Krita layer
> stack. Existing workflows with layer groups, masks, filters, etc. would
> work as expected with little or no additional work.
>
> This is implementable as a subclass of KisPaintLayer. All the frames
> associated with the animation layer would be contained here. As the active
> frame of the animation is changed, this class would swap the appropriate
> contents into view. I have made a quick prototype to test this concept and
> it works surprisingly well.
>

Yes, I totally agree with this solution. We had talks about that some time
ago. I'm not sure whether and to what extent they were implemented in the
animation branch.

There are actually two approaches for that: you can switch a paint device
in KisPaintLayer::paintDevice() or you can switch the data manager inside
the paint device itself. I would recommend the second approach, because in
many places in Krita (e.g. in KisCloneLayer) we store a pointer to other
layer's original, so switching the paint device would break at least clone
layers.

How to implement the idea.

1) Inside the paint device there are two approaches.

First approach is two switch the data manager manually (using a processing
applicator). Choosing this approach one should be very careful with: 1)
caches inside a paint device, like exactBounds() and thumbnail caches; 2)
undo information that is stored inside the data manager.

Second approach is to use strategies like we do for Wraparound mode. Every
paint device have strategies that choose which way the painting actions are
handled and how they are repeated across image boundaries. The choice of
the strategy is done basing on the value returned by KisDefaultBounds
object, which is a special interface for KisPaintDevice for accessing
global image data.

I would prefer using the first approach, because the second one has a
fundamental drawback. It involves a global variable in KisImage, which is
really difficult to handle.

2) When we ensure the paint device can switch it's data (it can be tested
with a unittest easily), the further animation support is really easy to
implement. One just needs to create a special layer with properties like:

a) which frame it points to
b) which offset relative to the current frame index it has (for onion skin
stuff)
c) should this frame be frozen

3) Another benefit of using the switching inside a paint device is that if
we copy data managers using a copy c-tor, we save quite a lot of memory,
because the tiles are shared between them.



> For file formats I see two main options: either a dedicated file format
> for animations, or including animations in the .kra format. The current
> implementation seems to favor the former approach, while I would prefer the
> latter. Instead of having two file formats, which are functionally nearly
> identical, a single format seems preferable as it would allow more fluid
> workflows and less specialized code. However, I can see arguments for both
> sides.
>

If the animation is implemented inside a single separate type of layer and
a paint device, then saving into .kra would be really easy. And then we
could just import/export into other formats.


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