<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Monday 14 September 2009, Boudewijn Rempt wrote:<br>
> If you want to filter tile-by-tile, you can already use the rect iterator,<br>
> which gives you the maximim number of contiguous bytes with every<br>
> iteration. <br>
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...)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> I don't want any code outside the tile engine to access pixel<br>
> data in any way other than through the iterators: we are not going to<br>
> expose tiles to filters and make filters responsible for cobbling together<br>
> tiles.<br>
+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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Cyrille Berger</p></body></html>