Hi!<br><br>I have thought about what to do for Krita. Including the ideas<br>mentioned in this thread, we have the following ideas:<br><br>1) Grayscale Selections<br>2) Fixing our 134 bugs :)<br>3) Optimization for speed (vectorization and etc)<br>
4) Porting the rest of Krita to the strokes<br>5) Recording system (as discussed in [1])<br>6) Memory footprint problem<br><br>All the tasks except of bug fixing are quite big and may take up to<br>several weeks of work. At the same time they are quite desirable for<br>
Krita and I have to spend some time on them. Probably, I<br>could interleave these big tasks and bugfixing, like 2 weeks for a<br>task + 2 weeks for bugs every month. What do you think about such<br>idea?<br><br>Actually, I'm not sure that all these tasks (or even "projects") can be<br>
done in four month (especially, including the time for bugfixing) so<br>we have to decide which are the most preferrable to us and what we can<br>do for every particular topic. Below I'll try to tell the ideas I have<br>
for each of them:<br><br>1) Grayscale Selections<br><br>I think, we surely need to do it. We speak about this feature for a<br>really long time. Boud made some progress in it some time ago. We must<br>complete it finally. I think, optimistically, it may take about two<br>
weeks.<br><br>3) Optimization for speed<br><br>Recently I've done some tests to find what I can do in the data<br>manager or merging code to make Krita faster and got no surprising<br>results. The data manager's code takes less than 1% of time (master,<br>
situation with enough of memory) and the merging takes 23% (6% of<br>it is composite op), which is not much as well. The greatest<br>portion of time is taken by the brush and compositeop code, which is<br>currently the area of Sven's work. If he wants, of course, I can do<br>
something in these area as well, but I guess, I should first try to do<br>some other important tasks in Krita.<br><br>4 and 5) Porting the rest of Krita to the strokes<br><br>I tried to compose a list of classes which are left to be ported to<br>
strokes. You can find the complete list here [2]. The tools, visitors<br>and commands should be definitely ported as part of this work. But the<br>situation with "actions" is a bit more complicated. I think this work<br>
should be done together with some steps towards the recording system<br>which we discussed before [1]. Otherwise the refactoring of their code<br>will be quite useless, because currently they work using the legacy<br>interface to the strokes system quite well.<br>
<br>I guess, I can do this in the following way: first, I do the porting<br>of tools, commands and visitors. This may take 1 or 2 weeks. And after<br>that I can start doing the basis for the recording system refactoring<br>
the actions on my way. I don't know how much time this work can take.<br><br>6) Memory footprint problem<br><br>Well, speaking truly, I have seen only few memory problems in<br>Krita. According to the massif we spend the memory on the following:<br>
<br>1. About constant 78MiB we spend on Gbr brushes, paintop presets and<br> pattrens.<br><br>2. 2% of your computer RAM is always spent on the pool of precloned<br> tiles. These tiles are cached to ease painting of next strokes.<br>
<br>3. Let the image takes N MiB of memory, then (N + h*N) MiB we spend on<br> storing the image and the history information. Currently the<br> swapper is configured in the following way:<br><br> - normally, Krita stores all the tiles (both history and image<br>
tiles) in RAM.<br><br> - when the amount of memory consumed reaches the level of 25% of<br> total RAM , Krita starts dumping the history tiles to the hard drive. <br> The process of dumping of history tiles stops either when Krita occupies <br>
less than 22% of memory or when there are no history tiles left in RAM. <br> When all the history tiles are gone, Krita continues to grow above the <br> 25% level.<br><br> - when the amount of memory consumed reaches the level of 50%, the<br>
swapper starts dumping real tiles and keeps the total memory on<br> this level.<br><br> Speaking truly, I don't see a reason why we should dump all the<br> history information immediately, but if you think it can make Krita<br>
faster we can change the default value for memorySoftLimitPercent<br> to zero and then no history information will be present in memory<br> ever. It will always be stored on a hard-drive.<br><br>4. QPainter canvas. For the QPainter canvas we store the copy of the<br>
image projection in memory (in a usual paint device). But (!) when<br> the color spaces of the image and the monitor coincide (I guess, it<br> is the common case now, but it will surely change) the two paint<br> devices share all the tiles, so this copy doesn't consume any extra<br>
memory. If the color spaces are different, e.g. image is 48bit,<br> then the tiles can't be shared and this paint device stores the<br> full copy of the projection.<br><br>5. OpenGL canvas. The case of the OpenGL canvas is even worse: it<br>
always stores the full copy of the image in form of tiled<br> textures. These tiles can be stored either in RAM (in case of<br> on-chip video) or in memory of graphics controller (in case of<br> discrete graphics).<br>
<br><br>Ok, so I can see the following things we can do with our memory<br>consumption:<br><br>1. Make GUI for the configuration of the swapper so everyone can<br> choose how much memory Krita's tiles take.<br><br>2. Try to set default value for history tiles in memory to 0 and see<br>
what results it will have.<br><br>3. Implement Region Of Interest (ROI) for the copy of the projection<br> in the UI. It means that this copy will store only the part of the<br> image that is actually shown on screen. The rest of the image will<br>
be fetched from KisImage->projection() on-demand. This will give a<br> benefit on high zooms, but will not give any help when the image is<br> shown "fit-page". And of course, it'll make panning and zooming a<br>
bit slower.<br><br> Such thing is not directly possible currently. The problem is that<br> all the data transfers are currently initiated by the KisImage. UI<br> cannot fetch any data from KisImage, because it can be in progress<br>
of calculation. But this problem can be solved in an elegant way:<br> when a user will pan (or zoom) the UI will create empty tiles (in<br> case of OpenGL) for these areas and temporarily show them on<br> screen. Then it will sent KisImage a signal saying it needs these<br>
areas and KisImage will deliver these parts of the image using<br> ususal mechanism sigImageUpdated(). This can be used for<br> krita-setch-rempt as well, btw.<br><br>4. If we do ROI we can prescale the image (using SSE, probably?)<br>
before transferring it to the UI. It could look like Mipmapping, <br> but we could store one level only. Say, the copy could store<br> the nearest power-of-two level of the image.<br><br>5. Implement a better compression for tiles going to the<br>
disk. E.g. with this algorithm [3]. I'm not sure how much it'll<br> give us.<br><br>6. We can play a bit with compression of tiles in memory. This is<br> possible right now: just increase swapWindowSize and swapSlabSize<br>
proportionally and decrease memory{Hard,Soft}LimitPercent. But I<br> doubt it'll give us anything.<br><br><br><br>Conclusion:<br><br>Well, I think I layed out too many ideas ;) And we should choose which<br>one should be implemented and which not.<br>
<br>I believe that the first two points (grayscale masks and bugs) are the<br>most important topics now. Currently, we can gain speed only from the<br>optimization of the brushes and composite ops. So after doing first<br>
two options I can either help Sven doing this (if needed) or start<br>working with strokes and recording. And juggling with memory<br>footprint... Speaking truly, I don't think that all the memory options<br>except the first two worth the effort. Currently, Krita eats as much<br>
memory as we tell it to eat, and the limiting factor now is not<br>memory, but calculations.<br><br>So, all the comments are welcome! :)<br><br><br><br>[1] - <a href="http://markmail.org/message/zzr3qlzdg7uwowir#query:+page:1+mid:qcnzymywucacrwhq+state:results">http://markmail.org/message/zzr3qlzdg7uwowir#query:+page:1+mid:qcnzymywucacrwhq+state:results</a><br>
[2] - <a href="http://dimula73.narod.ru/plan_for_krita_winter.html">http://dimula73.narod.ru/plan_for_krita_winter.html</a><br>[3] - <a href="http://old.nabble.com/Lossless-image-compression-td33272184.html">http://old.nabble.com/Lossless-image-compression-td33272184.html</a><br>
<br clear="all"><br>-- <br>Dmitry Kazakov<br>