sponsored work for Dmitry

Thu Sep 20 15:24:10 UTC 2012

Hi!

I have thought about what to do for Krita. Including the ideas
mentioned in this thread, we have the following ideas:

1) Grayscale Selections
2) Fixing our 134 bugs :)
3) Optimization for speed (vectorization and etc)
4) Porting the rest of Krita to the strokes
5) Recording system (as discussed in [1])
6) Memory footprint problem

All the tasks except of bug fixing are quite big and may take up to
several weeks of work. At the same time they are quite desirable for
Krita and I have to spend some time on them. Probably, I
could interleave these big tasks and bugfixing, like 2 weeks for a
task + 2 weeks for bugs every month. What do you think about such
idea?

Actually, I'm not sure that all these tasks (or even "projects") can be
done in four month (especially, including the time for bugfixing) so
we have to decide which are the most preferrable to us and what we can
do for every particular topic. Below I'll try to tell the ideas I have
for each of them:

1) Grayscale Selections

I think, we surely need to do it. We speak about this feature for a
really long time. Boud made some progress in it some time ago. We must
complete it finally. I think, optimistically, it may take about two
weeks.

3) Optimization for speed

Recently I've done some tests to find what I can do in the data
manager or merging code to make Krita faster and got no surprising
results. The data manager's code takes less than 1% of time (master,
situation with enough of memory) and the merging takes 23% (6% of
it is composite op), which is not much as well. The greatest
portion of time is taken by the brush and compositeop code, which is
currently the area of Sven's work. If he wants, of course, I can do
something in these area as well, but I guess, I should first try to do
some other important tasks in Krita.

4 and 5) Porting the rest of Krita to the strokes

I tried to compose a list of classes which are left to be ported to
strokes. You can find the complete list here [2]. The tools, visitors
and commands should be definitely ported as part of this work. But the
situation with "actions" is a bit more complicated. I think this work
should be done together with some steps towards the recording system
which we discussed before [1]. Otherwise the refactoring of their code
will be quite useless, because currently they work using the legacy
interface to the strokes system quite well.

I guess, I can do this in the following way: first, I do the porting
of tools, commands and visitors. This may take 1 or 2 weeks. And after
that I can start doing the basis for the recording system refactoring
the actions on my way. I don't know how much time this work can take.

6) Memory footprint problem

Well, speaking truly, I have seen only few memory problems in
Krita. According to the massif we spend the memory on the following:

1. About constant 78MiB we spend on Gbr brushes, paintop presets and
   pattrens.

2. 2% of your computer RAM is always spent on the pool of precloned
   tiles. These tiles are cached to ease painting of next strokes.

3. Let the image takes N MiB of memory, then (N + h*N) MiB we spend on
   storing the image and the history information. Currently the
   swapper is configured in the following way:

   - normally, Krita stores all the tiles (both history and image
     tiles) in RAM.

   - when the amount of memory consumed reaches the level of 25% of
     total RAM , Krita starts dumping the history tiles to the hard drive.
     The process of dumping of history tiles stops either when Krita
occupies
     less than 22% of memory or when there are no history tiles left in
RAM.
     When all the history tiles are gone, Krita continues to grow above the
     25% level.

   - when the amount of memory consumed reaches the level of 50%, the
     swapper starts dumping real tiles and keeps the total memory on
     this level.

   Speaking truly, I don't see a reason why we should dump all the
   history information immediately, but if you think it can make Krita
   faster we can change the default value for memorySoftLimitPercent
   to zero and then no history information will be present in memory
   ever. It will always be stored on a hard-drive.

4. QPainter canvas. For the QPainter canvas we store the copy of the
   image projection in memory (in a usual paint device). But (!) when
   the color spaces of the image and the monitor coincide (I guess, it
   is the common case now, but it will surely change) the two paint
   devices share all the tiles, so this copy doesn't consume any extra
   memory. If the color spaces are different, e.g. image is 48bit,
   then the tiles can't be shared and this paint device stores the
   full copy of the projection.

5. OpenGL canvas. The case of the OpenGL canvas is even worse: it
   always stores the full copy of the image in form of tiled
   textures. These tiles can be stored either in RAM (in case of
   on-chip video) or in memory of graphics controller (in case of
   discrete graphics).

Ok, so I can see the following things we can do with our memory
consumption:

1. Make GUI for the configuration of the swapper so everyone can
   choose how much memory Krita's tiles take.

2. Try to set default value for history tiles in memory to 0 and see
   what results it will have.

3. Implement Region Of Interest (ROI) for the copy of the projection
   in the UI. It means that this copy will store only the part of the
   image that is actually shown on screen. The rest of the image will
   be fetched from KisImage->projection() on-demand. This will give a
   benefit on high zooms, but will not give any help when the image is
   shown "fit-page". And of course, it'll make panning and zooming a
   bit slower.

   Such thing is not directly possible currently. The problem is that
   all the data transfers are currently initiated by the KisImage. UI
   cannot fetch any data from KisImage, because it can be in progress
   of calculation. But this problem can be solved in an elegant way:
   when a user will pan (or zoom) the UI will create empty tiles (in
   case of OpenGL) for these areas and temporarily show them on
   screen. Then it will sent KisImage a signal saying it needs these
   areas and KisImage will deliver these parts of the image using
   ususal mechanism sigImageUpdated(). This can be used for
   krita-setch-rempt as well, btw.

4. If we do ROI we can prescale the image (using SSE, probably?)
   before transferring it to the UI. It could look like Mipmapping,
   but we could store one level only. Say, the copy could store
   the nearest power-of-two level of the image.

5. Implement a better compression for tiles going to the
   disk. E.g. with this algorithm [3]. I'm not sure how much it'll
   give us.

6. We can play a bit with compression of tiles in memory. This is
   possible right now: just increase swapWindowSize and swapSlabSize
   proportionally and decrease memory{Hard,Soft}LimitPercent. But I
   doubt it'll give us anything.

Conclusion:

Well, I think I layed out too many ideas ;) And we should choose which
one should be implemented and which not.

I believe that the first two points (grayscale masks and bugs) are the
most important topics now. Currently, we can gain speed only from the
optimization of the brushes and composite ops. So after doing first
two options I can either help Sven doing this (if needed) or start
working with strokes and recording. And juggling with memory
footprint... Speaking truly, I don't think that all the memory options
except the first two worth the effort. Currently, Krita eats as much
memory as we tell it to eat, and the limiting factor now is not
memory, but calculations.

So, all the comments are welcome! :)

[1] -
http://markmail.org/message/zzr3qlzdg7uwowir#query:+page:1+mid:qcnzymywucacrwhq+state:results
[2] - http://dimula73.narod.ru/plan_for_krita_winter.html
[3] - http://old.nabble.com/Lossless-image-compression-td33272184.html

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