Yet another bug. This time filters vs selections

[Cyrille Berger]

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

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

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 shoould be exceptional and only if it 
gives a speed boost.

-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090914/0d807aa4/attachment.htm