Future of the animation feature

[Sven Langkamp]

On 12/21/14, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Saturday 20 December 2014 Dec 21:09:57 Timothée Giet wrote:
>
>> That is a good terminology explanation, I think.
>
> Okay, keeping this terminology, I think that it boils down to what Jouni
> already said: what's primary, the row, or the column -- the layer or the
> frame.
>
> So, we either create the concept of time, and place KisImage inside it, or
> take KisImage, and place the concept of time in KisImage. My thoughts were
> all going in the first direction, but under the shower I started thinking of
> the implications of the second direction.

I'm clearly in favor of putting the time into the image. It's better
to combine static with animated objects e.g. a static background with
several animated layers in front of it.

Beside that I think it would offer better performance. If you insert a
new layer the already composited parts stay the same.

> I'm not sure what will be easier, technically, when it comes to things like
> rendering the layerstack, preparing cached frames, swapping out KisNodes,
> but here are some points:

I think it's easier to implement. If you e.g. want to insert a new
layer into the image it's much simpler. If you have time outside of
the KisImage you have to sync all the images.

> * If we put the idea of time in KisImage, we shouldn't create special
> layers.

Agreed.

> * We should instead make time a first-class property of KisImage, with a
> 'still' image having just one frame.

Yes, KisImage should have a current frame which is the state that you
are working on. Changing that would move any layer with an animation
to the specified frame.

> * All layers (including group layers) should get the idea of time

Group layers should be timeless objects, so only the layers inside
them are animated. If the group layer had time, it would be possible
that the layers stack changes during the animation which I think is a
nightmare to manage.

So layer may or may not have animation support e.g. generate layer,
file layer or vector layer. These might need a totally different type
of animation.

> * Time should apply not just to paint devices, but also to properties like
> visibility, and for filter layers and masks, to the filter config.

I think things like visibility should be global e.g. the user might
want to watch the animation with one element hidden so he just hides
that layer.

Not sure how we model the changes of the properties.

> * Time should be managed by KisImage; we don't want individual layers have
> different ideas of frames and time, that would just lead to confusion.
>
> Here's another consequence: if we make KisImage contain the animation
> timeline, the core of the animation code goes into krita/image, otherwise it
> goes into krita/ui...
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>