Filter's changeRect() and merging problems

[Dmitry Kazakov]

>> I mean, KisImage::updateProjection is called three times on every
>> change. This causes prescaled projection to update a rect three times
>> instead of one! I've prepared a patch for that, but haven't committed
>> it yet [2]. Shall do it now. It's a temporary fix.
>>
>> I think it's better to brake this cycle. An update for the layer is
>> reported to KisImage once only. And it schedules it as it wishes.
>> This means that locks would be not per-layer-rect, but per-image-rect.
>
> Yes -- that was the idea. But so much code called either KisLayer::setDirty
> or KisPaintDevice::setDrity, that I routed the dirty setting via the
> layer to the image, to the projection.

That is not a problem. I think it's even better that all the requests
are coming through a unique "server". I creates a possibility to
control and schedule requests. That is good indeed!


> That should still cause only one
> call to KisProjection::updateProjection, though. And only from KisProjection
> should the signal be emitted that causes the prescaled projection to update.

Heh! =) KisLayer::setDirty is called from
KisTopDownUpdateProjection::setDirty() too. Just right from the
context of KisProjection. It causes a recursion. It works, but it
emits a signal for every layer updated. =) I've made a patch for this
mentioned above. Can i commit it?


> In any case, the image needs to know which layer was dirtied to make the
> update strategy start at the right place, so calling setDirty on the layer,
> which then calls the image is ok, I think, esp. since the image pointer might
> not be available everywhere.

Yes, it's ok

>> BUT! The problem is - gui is a separate thread and it reads projection
>
> The gui thread is the main application thread: I want the updating of
> the image projection done in one thread (once I used threadweaver and
> separated out the dirty areas and had several concurrent threads updating
> the projection, right now it's one thread that runs its own event loop
> and keeps the projetion updated), and then the prescaled/pyramid thing
> should do its work in the other thread.

> Like this:
>
> * The gui calls setDirty on the layer
> * the layer calls setDirty on the image
> * the image sends an async signal to KisProjection that a certain rect of a certain layer is dirty
> * KisProjection starts the recomposition, chunked to 512x512 pixel recs or something like that
> * For every chunk KisProjection creates a QImage of that chunk of the projection
> * emit an async signal with that QImage to KisCanvas
> * let KisCanvas use that: no calls from KisCanvas to KisImage's projection to read things.

but, the projection thread should _stop_ his work while the ui-thread
_is reading_ from a projection paint device.
And we can't use QImage:
1) KisImagePyramid uses usual paint devices for storage a pyramid. You
said we should have tiled cache.
2) Using QImage for transactions is yet another copy operation. I
don't thing it's good.

>> while KisGroupLayer writes to it. I think sigImageUpdated should be
>> split to two parts: first is synchronous - it reads a projection, the
>> second is asynchronous - prescales, draws and etc.
>>
>> But this is a subject for future investigation, cause Qt doesn't have
>> synchronous signals (has it?).
>
> Not across threads, afaik.

Quite bad. =(

-- 
Dmitry Kazakov