Future of the animation feature

[Boudewijn Rempt]

On Sun, 21 Dec 2014, Sven Langkamp wrote:

> 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.

But don't think in terms of 'the image' -- if the timeline is outside 
KisImage, we'd generate a KisImage for every frame, with references to the 
nodes used in the timeline.

>
>> * 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.


Well, no... Because grouplayers have visibility, and that needs to be 
animatable.

>
> 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.

Yes -- well, every layer has the basic animation of visibility, position, 
opacity, blending mode.

>
>> * 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.

Yes, and no -- the user for sure would like to be able to hide all of a 
layer in one go, but it's also necessary to toggle visibility, opacity 
etc. on a frame-by=frame base.

> Not sure how we model the changes of the properties.

BOudewijn