Yet another bug. This time filters vs selections

[Boudewijn Rempt]

On Mon, 14 Sep 2009, Dmitry Kazakov wrote:

> 2) In the future, when new tile engine gets activated, we'll optimize filter
> application. Filters will be applied tile-by-tile. This means that
> rectangles with underlying tiles of selections are not present simply won't
> be filtered.

In berlin, we already discussed ways of making the iterators faster. Currently,
a hline iterator retrieves a tile every time it passes a tile boundary. For
a horizontal filter that's 63 superfluous tile retrievals for every tile. That
can be optimized alot.

If you want to filter tile-by-tile, you can already use the rect iterator,
which gives you the maximim number of contiguous bytes with every iteration. 
I don't want any code outside the tile engine to access pixel data in any way 
other than through the iterators: we are not going to expose tiles to filters 
and make filters responsible for cobbling together tiles.

Side note: we already tried another approach before, namely using readBytes
and writeBytes to get larger chunks of pixels. That didn't help performance
much, although I never combined this filters. 

> 3) Of course, for realization of 2) we have to drop all the constant-time
> components from process function (like createTransformation()).

yes, that should be done in an initialization phase. It's even more important
because we already have the KisThreadedApplicator class that takes a filter,
and calls process on chunks of a paint device in a thread, so there it is
already a nasty inhibitor of performance.

About border issues: that is a big issue that hasn't been solved yet. There
are some filters that simply need access to all the pixels in a paint device
and cannot be chunked. That's why we have the supportsThreading flag.

Boudewijn