My ideas about GSOC Tiles project

[Dmitry Kazakov]

Good evening, everybody!

I would like to code Tiles GSOC project for krita. What should start with?

I have already thought over some general ideas of the future project and
wrote something like a "plan" for the project:

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.
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.
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.
More than that, layer-level mipmapping can be used while creating the
projection of the root layer.

Question. Could someone tell me, will the result be different in these two
situautions:
Assume we have two *PaintLayers*.
1) first we Merge them, then Scale down
2) first we Scale them down, then Merge
Will the result be different? (or, more precisely, will the result be *much*
different)

If the difference is too small, then we could use pyramid in KisMergeVisitor
to create a projection.

(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)

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.
In addition every tile should have it's own read/write semaphore.
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.

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.

4) Swapping to the PNG, TIFF

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?

If the latter is true, what is the meaning of "pluggable png-tiff backends"?

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.



Well, that's all i've understood from the code and project ideas pattern at
the wiki.

Could someone comment on this plan and tell me what should i do next?


PS:
What does KisProjection do? Where is it used? I've not seen it's
declarations in layers' classes.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090322/e15415c7/attachment.htm