<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Keep in mind that with double-paintdevice we iterate twice, and can't use<br>
KisRectIterator but have to use the much slower KisH/VLineIterator (until they<br>
are fixed to cache tiles, but I am rather sure the Rect one will remains<br>
fater).<br></blockquote><div><br>Hm.. Maybe you are right, though i don't understand you fully =) <br><br>If you have a single-paintdevice system, nevertheless you have to create _two_ iterators: one for read and one for write, what is the difference with double-paintdevice system? Could you explain it a bit more?<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And I also said that we need to investigate making copy cheaper, with for<br>
instance copy-on-write tiles for when you clone paint device, but could<br>
probably be usefull when bitBlting a copy. So the 2nd, could just be made by<br>
having a PaintDevice pointing to the old tiles, and I expect that operation to<br>
be reasonnably cheap.<br></blockquote><div><br>Ermm.. That is exactly the thing i was writing two letters above :)<br><br>We can't make it infinitely cheaper, because _creation_ of a datamanager object is quite expensive operation itself (because of initial creation of a hash table (see two letters above)).<br>
<br><br>Adding shared tiles to a bitBlt operation is an extremely good idea, but it should take into account colorspaces. Do you have an idea how to solve this?<br>(we could discuss it on sprint)<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have been a strong advocate of the src/dst API, based on the assumption that<br>
copying was expensive, and that for features such as masks or paint with filter<br>
the copying would be a burden. But now, based on the experience we have build<br>
with that API, I see significant drawback:<br>
1) not possible to use KisRectIterator<br></blockquote><div><br>Isn't it possible to fix KisRectIterator instead?<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) double the number of tiles retrieval (or even mutliply the number of<br>
retrieval by 2*64 for the current non optimized KisH/VLineIterator)<br></blockquote><div><br>How is it connected to an API? Could you explain?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) confusing API, since iterators already include a src/dst mechanism with the<br>
oldRawData/rawData functions, and as we can see it, making filters work<br>
correctly with that API is quiet difficult<br></blockquote><div><br>
oldRawData/rawData are not src/dst really. They are oldRawData and rawData actually! :)<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The drawback of having single-src:<br>
1) the need to first copy the data<br>
<br>
But if copy get cheap, and I trully think it can be cheap, then I think we can<br>
get significant improvement. Both API and performance wise.<br></blockquote><div><br>Please read above.<br>But in this very case, cheap copy would help, because we already create additional paintDevice nevertheless.<br clear="all">
</div></div><br>-- <br>Dmitry Kazakov<br>