Yet another bug. This time filters vs selections

[Boudewijn Rempt]

On Monday 14 September 2009, Cyrille Berger wrote:
> On Monday 14 September 2009, Boudewijn Rempt wrote:
> > 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 have been thinking about that. The reason we are not using rect iterators
> anymore is that it doesn't offer guarantee of alignment between two paint
> devices. This cause problem if src != dst, and if you iterate over a
>  selection at the same time. But assuming that we don't iterate over
>  selection, maybe we can also drop the constraint of src can be dst (and
>  after all remove the dst parameter, would be only possible for 2.2). But I
>  think, we can do that only, and only, if copying data from paint device or
>  cloning them is relatively cheap. (and I am wondering if it couldn't be
>  cheaper, at least cloning, than having two iterators...)

Sven did some research on readbytes/writebytes -- which is effectively cloning 
of paint devices in the a cheap possible way. Cheaper still would be a deep 
copy of all the tiles touched by a rect -- maybe something to investigate.

> > 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.
> 
> +1000 :) and using iterators increase maintanbility. And anyway, I would
>  doubt iterators add much overhead, at least, callgrind usually blame tiles
>  retrieval, so I agree that strategy that limit tiles retrieval should be
>  investigated instead.

Yes.

> That said it might be worth to delegate some operations to the data manager
> (bitBlit or copy for instance), if it means they can be more efficient,
>  since we would be calling them more, but that should be exceptional and
>  only if it gives a speed boost.

Premature optimization and all that being what it is, I'd be wary of it. Also, 
right now the tile manager doesn't know anything about pigment. Moving bitblt 
in there would expose pigment to the tile engine. Not that that is necessarily 
a problem, but it would complicate things.

And apart from pigment, the current code in KisPainter::bitblt is still pretty 
fast thanks to the cached tiles in the random accessor, which suggest that 
agressive caching could be a cheap win.

-- 
Boudewijn Rempt | http://www.valdyas.org