<div class="gmail_quote">On Thu, Mar 26, 2009 at 6:57 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Tuesday 24 March 2009, Dmitry Kazakov wrote:<br>
<br>
> Maybe we are both right ;) The implementation should be spread between<br>
> KisDataManager and KisPaintDevice. Now i've got how to describe that:<br>
><br>
> We have to add a new layer of abstraction (not sure this term is right<br>
> here) to these classes: that is "current zoom level".<br>
<br>
</div>Yes, I think you are right at that. It is a bit of a pity, since I've tried to<br>
make krita/image as independent of any display considerations as possible, but<br>
I think it cannot be helped. It also means that the KisDataManager needs to<br>
know about the colorspace, so the scaling algorithms can work.</blockquote><div><br>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:<br>
<br>case1:<br>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.<br>
<br>case2:<br>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.<br>
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.<br><br>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.<br>
<br>Another question is, where should we colour correct? It should be done after layers merged, obviously. In KisImage->d->m_projection, i guess.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
> ><br>
> > following Qt4 api<br>
> > conventions.<br>
><br>
> Where should i read about it?<br>
<br>
</div>Gosh... I'm not sure I can retrieve the link. Basically, Qt tries to get away<br>
from true/false flags in their api because they can be confusing and instead<br>
defines an enum so you can pass sensible, descriptive paramenters.<br>
<div></div></blockquote><div><br>Hm.. then it's not a qt's invention:) I thought enums are something like a general practice in programming =)<br>They used everywhere in linux-kernel.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
> Ideally we shouldn't compose layers at all, we should compose tiles, but i<br>
> can't imagine how atm :)<br>
<br>
</div>That's complicated because tile boundaries are not necessarily congruous: that<br>
is, if a paint device is moved from 0,0, it's origin moves, the content of the<br>
tiles isn't moved.<br>
<div></div></blockquote><div><br>I think it's not the worst problem. By the way where this paint device moving used?<br><br>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).<br>
By the way, do our "blending modes" for KisPaintLayers use something like convolution? So to say, can two KisPaintLayers be merged tile by tile?<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Something like Read-copy-update (RCU) in linux? I guess it's too weird for<br>
> that.<br>
<br>
</div>I think it's the same idea -- copy-on-write and rcu.</blockquote><div><br>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.<br>
<br>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.<br>
<a href="http://en.wikipedia.org/wiki/Read-copy-update">http://en.wikipedia.org/wiki/Read-copy-update</a><br>I don't think it can be applied to tiles =(<br><br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
> What was the cause of this boost?<br>
<br>
</div>Less allocations -- we'd allocate a big tile pool once, and give every paint<br>
device tiles from this pool, instead of allocating a pool per paint device.<br>
Especially since we create and discard paint devices a whole lot in krita.<br>
<div></div></blockquote><div><br>And it's easier to implement COW with united pool, i guess.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
> Taking into account the parallel thread about full-time working. I have<br>
> four exams at the university in the beginning of June, but i hope to manage<br>
> to pass two of them in advance in May. So at least two of them are left for<br>
> June and it'll take at least 9 days. Can it prevent me from GSOC?<br>
<br>
</div>That should be okay.<br></blockquote></div>Great! =)<br><br clear="all"><br>-- <br>Dmitry Kazakov<br>