Filter's changeRect() and merging problems

[Boudewijn Rempt]

On Mon, 24 Aug 2009, Dmitry Kazakov wrote:

> Aha! That's why we get this large cycle though all code on merging =)
> 
> 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 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.

I seem to remember there being some problem with the naming of signals and 
slots that caused something like you describe -- but didn't I commit a fix 
for that already?

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.

> I think that old scheduler could have yet another trouble. I mean that
> updateStrategy has a shared structure - filthyNode.
> 
> [2] - http://reviewboard.kde.org/r/1347/

I need to check on that, that's not soemthing I'm completely clear about now.

> 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.

> 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.

> All i want to say, these three bugs (merging adj. layers, flickering
> and threading KisProjection) should be solved together, as a whole.

I agree ith that.