Krita performance.

[Sven Langkamp]

On Tue, May 21, 2013 at 9:48 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

> HI!
>
> As far as I can see, we have two approaches here (and,  probably, we
> should do something with both of them):
>
> 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.
>

There is a difference between the two methods. The normal fill needs to
check the pixels for the threshold which makes it slower.


> 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.
>
> 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.
>

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.


> This approach has at least two (a bit) complex tasks:
> 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.
> 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:
>
> ROOT
>    PAINT1
>    GROUP1
>       PAINT2
>       PAINT3 <-- active
>       PAINT4
>       PAINT5
>       PAINT6
>    PAINT7
>    PAINT8
>    PAINT9
>    PAINT10
>    PAINT11
>
> This stack can be shrunk to 6 layers, not depending on how many children
> the two group layers have.
>

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.


> Such compression is essential if we want to move some part of Krita to GPU.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130522/142ee54b/attachment.html>