[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Future of the animation feature
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2014-12-22 9:10:41
Message-ID: CAEkBSfUxO3gVixZ6S6w7Ov1RQD0Z7Jj_ynjXAsg0Y1tHw6W4Dw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Dec 21, 2014 at 6:27 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
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.
>
A separate KisImage for every frame is a nice idea, but we need to answer
two questions:
1) How would we handle static layers? Are they going to be duplicated in
every frame? Right now all the types of layers store a pointer to the image
(KisDefaultBounds in every KisNode + a direct pointer in every KisLayer).
Also clone layers have a bidirectional link with its source, which is used
for projection calculation every time. Every paint device inside a layer
also stores a pointer to KisImage via KisDefaultBounds.
These pointers were the reason why I decided to implement LOD by switching
datamanagers inside a paint device, instead of switching paint devices in
layers.
2) Memory management. All the duplicated node will occupy extra memory.
Krita's tile engine has copy-on-write mechanism, but it works only on
direct copies of paint devices. If we save the duplicated nodes into .kra
and load them afterwards, the memory will be duplicated.
---
Dmitry Kazakov
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec \
21, 2014 at 6:27 PM, Boudewijn Rempt <span dir="ltr"><<a \
href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> \
wrote:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""></span> \
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.<span class=""></span><br></blockquote></div><br></div><div \
class="gmail_extra">A separate KisImage for every frame is a nice idea, but we need \
to answer two questions:<br><br></div><div class="gmail_extra">1) How would we handle \
static layers? Are they going to be duplicated in every frame? Right now all the \
types of layers store a pointer to the image (KisDefaultBounds in every KisNode + a \
direct pointer in every KisLayer). Also clone layers have a bidirectional link with \
its source, which is used for projection calculation every time. Every paint device \
inside a layer also stores a pointer to KisImage via KisDefaultBounds. <br><br>These \
pointers were the reason why I decided to implement LOD by switching datamanagers \
inside a paint device, instead of switching paint devices in \
layers.<br><br></div><div class="gmail_extra">2) Memory management. All the \
duplicated node will occupy extra memory. Krita's tile engine has copy-on-write \
mechanism, but it works only on direct copies of paint devices. If we save the \
duplicated nodes into .kra and load them afterwards, the memory will be \
duplicated.<br><br></div><div class="gmail_extra"><br><br>---<br><div \
class="gmail_signature">Dmitry Kazakov</div> </div></div>
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic