<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I guess, we could implement a kind of scaled down cache in the KisImage. Then some actions (which are designed to support it) may be applied by the strokes framework first on the scaled down image and later on the original one. As stroked framework works in the background the UI will not be blocked during these actions.<br>

</blockquote><div><br></div></div><div>I think you this would need to go through the entire layer stack. </div></div></div></div></blockquote><div><br>Yes, sure. That's why I suggest doing an optimization of the stack and of the cache stack. And if we want to implement this incrementally, we could first implement a single-node cache and then extend it to a graph.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Each node would have a mipmap with e.g. an 1/4 and 1/16 layer.</div>
</div></div></div></blockquote><div><br>Well, I really think we do *not* need mipmapping. Zooming is not so frequent usecase for us in comparison with opengl. What we need is a cache of a single zoom-level. I'm not sure which zoom-level it should be: it might be current zoom-level or aligned to power-of-two level. But we surely don't need to keep the whole mipmap structure.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ROOT<br>   PAINT1<br>   GROUP1<br>      PAINT2<br>      PAINT3 <-- active<br>      PAINT4<br>      PAINT5<br>      PAINT6<br>   PAINT7<br>   PAINT8<br>   PAINT9<br>   PAINT10<br>   PAINT11<br><br>This stack can be shrunk to 6 layers, not depending on how many children the two group layers have.<br>

</blockquote><div><br></div></div><div>I wonder how you get the 3 * G number. In the above example I would assume that you could cache 7-11, 5-6 and then have 3, 2, group1, 1 and root as layers. If there was a layer between Paint1 and Group1 you would need an additional layer unless only the over composite op would be used.</div>
</div></div></div></blockquote><div><br>Well, yes, there are exceptions for at least Adjustment Layers: if they are in N_ABOVE_FILTHY state [0], then they cannot be merged with the others. Probably, there are some exceptions for some specific composite ops, but I'm not sure currently. Anyway, these exceptions should be taken into account for the cache.<br>
 <br><br>[0] - see KisAsyncMerger for the states<br></div></div><br>-- <br>Dmitry Kazakov