<div dir="ltr">On Tue, May 21, 2013 at 9:48 PM, Dmitry Kazakov <span dir="ltr"><<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">HI!<br><br>As far as I can see, we have two approaches here (and,  probably, we should do something with both of them):<br>
<br>1) Optimize the Fill and Gradient itself, because as reported by myfth "Fill Entire Selection" works much faster than usual Fill Tool. So there is a bit of room for improvement.<br></blockquote><div><br></div>
<div style>There is a difference between the two methods. The normal fill needs to check the pixels for the threshold which makes it slower. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2) As Sven said, do something really different. I thought about it, when was experimenting with cuda and later after discussing the performance with Lukas during the sprint. I have such a feeling, that PS first applies all the actions on the scaled down image, and only later, processes the whole image in the background. That is seen when pressing OK in the filter dialog: your image blinks after a couple of seconds after you click it, although the filter keeps applied both before and after the click.<br>

<br>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 style>I think you this would need to go through the entire layer stack. Each node would have a mipmap with e.g. an 1/4 and 1/16 layer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This approach has at least two (a bit) complex tasks:<br>1) We need to implement actions for Fill,Gradient tools and Filters so that they can be applied to the scaled down image. This is actually not very difficult but it needs a bit of time.<br>

2) It is not fun to keep a copy of the whole layer stack (and a scaled copy of it) and merge many layers every time. Any image stack can actually be shrunk to 3 * G layers, where G is the number of parent layers of the currently active layer. That is:<br>

<br>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 style>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Such compression is essential if we want to move some part of Krita to GPU.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote></div></div></div>