[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Krita performance.
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2013-05-22 6:16:30
Message-ID: CAEkBSfW_bWsmZqXutSgbivDoq2CtpYtb9BMf0_+pYbWe0jHfmQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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
[Attachment #5 (text/html)]
<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
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic