Yet another bug. This time filters vs selections

[Dmitry Kazakov]

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

I won't! promise! =)


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

Iterators are not panacea. And if we have code-duplication with iterators or
not it won't increase any maintainability.


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

At the moment we already have some (at least with my engine):
1) clear(rect, color) - fills the @rect with @color. If the rect is big
enough filling is done in a cheap way - tiles are shared.
2) copy-constructor - duplicates a dataManager in a shared (deferred) way.
It means that no actual copying is done synchronously. So you can use this
to optimize code.




-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090914/9914d880/attachment.htm