Filter's changeRect() and merging problems

[Boudewijn Rempt]

On Mon, 24 Aug 2009, Dmitry Kazakov wrote:

> Hi, Boud!
> 
> What bookkeeping do you mean?

It used to work like this:

on painting:
* call layer->setDirty: add the rect to a QRegion that represents the total dirty area on the layer
* emit a signal to KisProjection to add the rect to the total dirty area of the image
* KisProjection would, starting with the visible area, update in a number of subthreads parts of the
dirty area
* as soon as the bottom-up update strategy had recomputed an area of a layer, that rect would be
subtracted from the QRegion

So, every layer at any point in time knew which area was dirty. But QRegion isn't threadsafe,
and putting mutexes around the dirty area gave us lots of deadlocks.

All this code is still around, for instance in http://websvn.kde.org/tags/koffice/1.9.95.1/krita/image/.

> Current top-down approach has an issue too - it's not stateless.
> FilthyNode is global. I want to make merging with recursion. In such a
> case all the data will be stored in a local stack, so it'll be a bit
> more thread-safe. But that is not my aim, itself. First i want to add
> needRects to merging. This'll fix adj. layers bug. [1]
> 
> Secondly, i want to make this stuff thread-safe, by splitting update
> regions into non-overlapping areas. This, coupled with synchronization

That's something I simply never managed to do correctly.

> with KisCanvas, would eliminate flickering while painting, that is too
> heavy now due to race conditions between threads.

As long as the recomposition of the image's projection stays in a separate
thread and doesn't go back to the gui thread, I'm okay with what you propose
to do, but it should be easy to back out of in case we don't get it stable for
the release. It is a bug fix -- but the fix you propose is really invasive.

Boudewijn