<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 21/12/2014 15:27, Boudewijn Rempt a
écrit :<br>
</div>
<blockquote
cite="mid:alpine.LNX.2.00.1412211523460.25970@calcifer.valdyas.org"
type="cite">On Sun, 21 Dec 2014, Sven Langkamp wrote:
<br>
<br>
<blockquote type="cite">On 12/21/14, Boudewijn Rempt
<a class="moz-txt-link-rfc2396E" href="mailto:boud@valdyas.org"><boud@valdyas.org></a> wrote:
<br>
<blockquote type="cite">On Saturday 20 December 2014 Dec
21:09:57 Timothée Giet wrote:
<br>
<br>
<blockquote type="cite">That is a good terminology
explanation, I think.
<br>
</blockquote>
<br>
Okay, keeping this terminology, I think that it boils down to
what Jouni
<br>
already said: what's primary, the row, or the column -- the
layer or the
<br>
frame.
<br>
<br>
So, we either create the concept of time, and place KisImage
inside it, or
<br>
take KisImage, and place the concept of time in KisImage. My
thoughts were
<br>
all going in the first direction, but under the shower I
started thinking of
<br>
the implications of the second direction.
<br>
</blockquote>
<br>
I'm clearly in favor of putting the time into the image. It's
better
<br>
to combine static with animated objects e.g. a static background
with
<br>
several animated layers in front of it.
<br>
<br>
Beside that I think it would offer better performance. If you
insert a
<br>
new layer the already composited parts stay the same.
<br>
<br>
<blockquote type="cite">I'm not sure what will be easier,
technically, when it comes to things like
<br>
rendering the layerstack, preparing cached frames, swapping
out KisNodes,
<br>
but here are some points:
<br>
</blockquote>
<br>
I think it's easier to implement. If you e.g. want to insert a
new
<br>
layer into the image it's much simpler. If you have time outside
of
<br>
the KisImage you have to sync all the images.
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">
<br>
<blockquote type="cite">* If we put the idea of time in
KisImage, we shouldn't create special
<br>
layers.
<br>
</blockquote>
<br>
Agreed.
<br>
<br>
<blockquote type="cite">* We should instead make time a
first-class property of KisImage, with a
<br>
'still' image having just one frame.
<br>
</blockquote>
<br>
Yes, KisImage should have a current frame which is the state
that you
<br>
are working on. Changing that would move any layer with an
animation
<br>
to the specified frame.
<br>
<br>
<blockquote type="cite">* All layers (including group layers)
should get the idea of time
<br>
</blockquote>
<br>
Group layers should be timeless objects, so only the layers
inside
<br>
them are animated. If the group layer had time, it would be
possible
<br>
that the layers stack changes during the animation which I think
is a
<br>
nightmare to manage.
<br>
</blockquote>
<br>
<br>
Well, no... Because grouplayers have visibility, and that needs to
be animatable.
<br>
<br>
<blockquote type="cite">
<br>
So layer may or may not have animation support e.g. generate
layer,
<br>
file layer or vector layer. These might need a totally different
type
<br>
of animation.
<br>
</blockquote>
<br>
Yes -- well, every layer has the basic animation of visibility,
position, opacity, blending mode.
<br>
<br>
<blockquote type="cite">
<br>
<blockquote type="cite">* Time should apply not just to paint
devices, but also to properties like
<br>
visibility, and for filter layers and masks, to the filter
config.
<br>
</blockquote>
<br>
I think things like visibility should be global e.g. the user
might
<br>
want to watch the animation with one element hidden so he just
hides
<br>
that layer.
<br>
</blockquote>
<br>
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.
<br>
<br>
</blockquote>
<br>
About opacity, what an animator will need is not directly
frame/frame values, but rather to set keyframe values and get
interpolation between keys. This could be better handled using a
curve in the timeline (we could have foldable settings curves for
each layers in the timeline..).<br>
<br>
Visibility could be animated switching opacity 0-100%.<br>
<br>
This way we could keep visibility button to hide a layer, and maybe
keep the opacity animation relative to layer opacity slider value.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:alpine.LNX.2.00.1412211523460.25970@calcifer.valdyas.org"
type="cite">
<blockquote type="cite">Not sure how we model the changes of the
properties.
<br>
</blockquote>
<br>
BOudewijn<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Krita mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kimageshop@kde.org">kimageshop@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kimageshop">https://mail.kde.org/mailman/listinfo/kimageshop</a>
</pre>
</blockquote>
<br>
</body>
</html>