My ideas about GSOC Tiles project
dimula73 at gmail.com
Fri Mar 27 13:54:52 CET 2009
On Thu, Mar 26, 2009 at 6:57 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Tuesday 24 March 2009, Dmitry Kazakov wrote:
> > Maybe we are both right ;) The implementation should be spread between
> > KisDataManager and KisPaintDevice. Now i've got how to describe that:
> > We have to add a new layer of abstraction (not sure this term is right
> > here) to these classes: that is "current zoom level".
> Yes, I think you are right at that. It is a bit of a pity, since I've tried
> make krita/image as independent of any display considerations as possible,
> I think it cannot be helped. It also means that the KisDataManager needs to
> know about the colorspace, so the scaling algorithms can work.
I think KisPaintDevice&KisDataManager should be as independent of other
classes as possible. They should encapsulate all the methods of scaling. The
rest of the classes would just request a needed image. But this paradigm
have a few mismatches with merging. There are two cases possible:
We keep mipmapped only KisImage->d->m_projection. All the KisPaintLayers use
regular non-mipmapped paintDevices. When projection should be updated,
m_projection requests _changed_ tiles only, merges them and rebuilds
(partly) image-tree. This case doesn't mismatch with idea of encapsulating
everything into paintDev&dataManager.
We keep mipmapped both KisImage->d->m_projection and KisPaintLayers. Why
could it be useful? It's useful for preview of operations that need whole
image to process (e.g. for filters). When a filter window shows, it sets
current zoom-level for KisImage->d->m_projection to something like 50%, and
merging is done at this level.
I think this case is better as it's more flexible. But it takes much power
to keep image-trees for all the layers and it brakes the paradigm of
encapsulation. I think we should experiment with this.
An issue with "m_projection requests _changed_ tiles" could be done with
tile-versioning. Every tile could have a revision that was used by KisImage
to keep the projection up-to-date. But it's quite difficult to implement and
we have to think over it properly.
Another question is, where should we colour correct? It should be done after
layers merged, obviously. In KisImage->d->m_projection, i guess.
> > >
> > > following Qt4 api
> > > conventions.
> > Where should i read about it?
> Gosh... I'm not sure I can retrieve the link. Basically, Qt tries to get
> from true/false flags in their api because they can be confusing and
> defines an enum so you can pass sensible, descriptive paramenters.
Hm.. then it's not a qt's invention:) I thought enums are something like a
general practice in programming =)
They used everywhere in linux-kernel.
> > Ideally we shouldn't compose layers at all, we should compose tiles, but
> > can't imagine how atm :)
> That's complicated because tile boundaries are not necessarily congruous:
> is, if a paint device is moved from 0,0, it's origin moves, the content of
> tiles isn't moved.
I think it's not the worst problem. By the way where this paint device
The worst problems are hiding in border-effects, i guess. E.g.
filter-layers, that use convolution. We can't apply them to the part of the
image (or it is too complicated).
By the way, do our "blending modes" for KisPaintLayers use something like
convolution? So to say, can two KisPaintLayers be merged tile by tile?
> > Something like Read-copy-update (RCU) in linux? I guess it's too weird
> > that.
> I think it's the same idea -- copy-on-write and rcu.
We seem to speak about different things =) Speaking strictly, COW is not a
synchronization primitive. It's something like lazy tiles-caching system. It
can't help us when two threads (e.g. worker and main thread) are requesting
the same tile. Of course it should be present in tiles subsystem, but it
should be built on some common locking system.
RCU is a synchronization technique. In linux it is used for data, that is
mostly read. Reading is made without any locks, but in non-preemptive mode.
When you want to write to this area, you clone it, write to the copy and at
last swaps original pointer for a new one.
I don't think it can be applied to tiles =(
> > What was the cause of this boost?
> Less allocations -- we'd allocate a big tile pool once, and give every
> device tiles from this pool, instead of allocating a pool per paint device.
> Especially since we create and discard paint devices a whole lot in krita.
And it's easier to implement COW with united pool, i guess.
> > Taking into account the parallel thread about full-time working. I have
> > four exams at the university in the beginning of June, but i hope to
> > to pass two of them in advance in May. So at least two of them are left
> > June and it'll take at least 9 days. Can it prevent me from GSOC?
> That should be okay.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop