<div dir="ltr">Hi, Jouni!<br><br><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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 :)<br><br></div><div>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 <a href="http://creately.com">http://creately.com</a> They allow create public diagrams and edit them collaboratively.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br><br></div><div>How to implement the idea.<br><br></div><div>1) Inside the paint device there are two approaches. <br><br>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.<br><br></div><div>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. <br><br></div><div>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.<br><br></div><div>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:<br><br></div><div>a) which frame it points to<br></div><div>b) which offset relative to the current frame index it has (for onion skin stuff)<br></div><div>c) should this frame be frozen<br><br></div><div>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. </div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br></blockquote><div><br></div><div>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.<br></div><div><br> </div></div>-- <br><div class="gmail_signature">Dmitry Kazakov</div>
</div></div>