Good evening, everybody!<br><br>I would like to code Tiles GSOC project for krita. What should start with?<br><br>I have already thought over some general ideas of the future project and wrote something like a "plan" for the project:<br>
<br>1) The first thing to implement is Mipmapping. I've come to a conclusion that mipmapping should be done at the level of Layer's projection (e.g. KisPaintLayer::Private {KisMipmappedPaintDevice projection; ...}). This KisMipmappedPaintDevice class should be derived from KisPaintDevice and support most of it's methods. The difference is that mipmapped class will have pyramid of scaled images. <br>
Why should it be put here? Let's look at the case when we have the only PaintLayer. In such a case, applying of any paintop we'll change 1-2 tiles. All the rest tiles will be untouched, and of course their scaled-down versions will stay untouched too. It turnes out that we have to scale only 1-2 tiles instead of scaling the whole image. <br>
The things are a bit more difficult with Adjustment Layers because most of them need the whole image for processing. But there are a few filters that could benefit from mipmapping at the layer stage. E.g. Perchannel Filter. It could process scaled-down picture while previewing (previewing is the _worst_ thing in this filter at the moment). All the filters could have a method KisFilter::NeedsOriginalImage() that would say whether filter can work on downscaled image.<br>
More than that, layer-level mipmapping can be used while creating the projection of the root layer.<br><br>Question. Could someone tell me, will the result be different in these two situautions:<br>Assume we have two *PaintLayers*. <br>
1) first we Merge them, then Scale down<br>2) first we Scale them down, then Merge<br>Will the result be different? (or, more precisely, will the result be *much* different)<br><br>If the difference is too small, then we could use pyramid in KisMergeVisitor to create a projection.<br>
<br>(the last issue can't be applied in case we have at least one Adjustment Filter in the stack, in this case we should consult with KisFilter::NeedsOriginalImage() first. BUT this approach works well with Filter Masks, as in such a case filters brake only one pyramid that can be quickly recalculated)<br>
<br>2) Locking and threading. I think locking should be made something like linux kernel's deferred irq subsystem. Every MipmappedPaintDevice should have its own working thread. Most of the time it sleeps on it's working_queue's semaphore. When work appears it goes to work_queue, the semaphore gets up and thread goes on calculating piramids for the tiles listed in workqueue.<br>
In addition every tile should have it's own read/write semaphore.<br>2b) Swapping. Again, one KisTiledDataManager - one swapper thread. This thread could work without workqueue. Just go though existing tiles and find unneeded. The concurrent access to tiles is controlled by tile's RW-semaphore.<br>
<br clear="all">3) In memory compression. I'm not sure i'll have time for good on-the-fly compression engine, but it can be made in swapper thread.<br><br>4) Swapping to the PNG, TIFF<br><br>Question. Could someone tell me, can tiff or png save to file only parts of the image? Or they need the whole image for compressing?<br>
<br>If the latter is true, what is the meaning of "pluggable png-tiff backends"?<br><br>5) Undo information. I've not thought about it properly. But is done at the level of tiles and won't disturb projections, i hope.<br>
<br><br><br>Well, that's all i've understood from the code and project ideas pattern at the wiki.<br><br>Could someone comment on this plan and tell me what should i do next?<br><br><br>PS:<br>What does KisProjection do? Where is it used? I've not seen it's declarations in layers' classes.<br>
<br>-- <br>Dmitry Kazakov<br>