[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Krita performance.
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2013-05-22 2:53:46
Message-ID: CAAmsBf=Fms4b6mTwrg5J0gwh2H-9_BfG6G=d8-woDfKup1LXUw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, May 21, 2013 at 9:48 PM, Dmitry Kazakov <dimula73@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.
>
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
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