Krita performance.

[Dmitry Kazakov]

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

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.


> Each node would have a mipmap with e.g. an 1/4 and 1/16 layer.
>

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.

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

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.


[0] - see KisAsyncMerger for the states

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130522/b231d388/attachment.html>