Krita performance.

Dmitry Kazakov dimula73 at
Tue May 21 19:48:22 UTC 2013


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

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:

      PAINT3 <-- active

This stack can be shrunk to 6 layers, not depending on how many children
the two group layers have.

Such compression is essential if we want to move some part of Krita to GPU.

Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kimageshop mailing list