sponsored work for Dmitry

silvio grosso grossosilvio at yahoo.it
Thu Sep 20 16:36:10 UTC 2012 

Hi everyone,

Dmitry wrote:
> I believe that the first two points (grayscale masks and bugs) are the
most important topics now.

I totally agree :-)

1. The Grayscale mask feature has been suggested several times by many users-artists.

2. The great importance of fixing bugs does not need an explication :-)

On the one hand, fixing bugs is a "boring-nasty" task.
Usually, it is more fun to develop something completely new (besides you generally get much more visibility as a developer). 
On the other hand, it requires someone *really* skilled to do this fixing correctly.
That is, someone who does not  break other parts of the software (while fixing the bugs) :-)

I have been always delighted by the Blender team (but the same applies to other softwares: e.g. LibreOffice).
On Mondays, the Blender team always releases a report and their first item is usually the bug-count.
In this report they list the total amount of bugs (and the number of bugs fixed):
http://www.blendernation.com/2012/09/16/developer-meeting-notes-september-16-2012/
In  my view, they show a very *professional* attitude :-)

Best regards,

Silvio



--- Gio 20/9/12, Dmitry Kazakov <dimula73 at gmail.com> ha scritto:

Da: Dmitry Kazakov <dimula73 at gmail.com>
Oggetto: Re: sponsored work for Dmitry
A: "Krita's developers and users mailing list" <kimageshop at kde.org>
Data: Giovedì 20 settembre 2012, 17:24

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


-----Segue allegato-----

_______________________________________________
kimageshop mailing list
kimageshop at kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120920/1b3951b1/attachment-0001.html>

More information about the kimageshop mailing list