Keep in mind that with double-paintdevice we iterate twice, and can't use
KisRectIterator but have to use the much slower KisH/VLineIterator (until they
are fixed to cache tiles, but I am rather sure the Rect one will remains
fater).
Hm.. Maybe you are right, though i don't understand you fully =)
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?
And I also said that we need to investigate making copy cheaper, with for
instance copy-on-write tiles for when you clone paint device, but could
probably be usefull when bitBlting a copy. So the 2nd, could just be made by
having a PaintDevice pointing to the old tiles, and I expect that operation to
be reasonnably cheap.
Ermm.. That is exactly the thing i was writing two letters above :)
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)).
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?
(we could discuss it on sprint)
I have been a strong advocate of the src/dst API, based on the assumption that
copying was expensive, and that for features such as masks or paint with filter
the copying would be a burden. But now, based on the experience we have build
with that API, I see significant drawback:
1) not possible to use KisRectIterator
Isn't it possible to fix KisRectIterator instead?
2) double the number of tiles retrieval (or even mutliply the number of
retrieval by 2*64 for the current non optimized KisH/VLineIterator)
How is it connected to an API? Could you explain?
3) confusing API, since iterators already include a src/dst mechanism with the
oldRawData/rawData functions, and as we can see it, making filters work
correctly with that API is quiet difficult
oldRawData/rawData are not src/dst really. They are oldRawData and rawData actually! :)
The drawback of having single-src:
1) the need to first copy the data
But if copy get cheap, and I trully think it can be cheap, then I think we can
get significant improvement. Both API and performance wise.
Please read above.
But in this very case, cheap copy would help, because we already create additional paintDevice nevertheless.