dimula73 at gmail.com
Sun Oct 4 20:46:51 CEST 2009
> 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
> are fixed to cache tiles, but I am rather sure the Rect one will remains
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
> having a PaintDevice pointing to the old tiles, and I expect that operation
> 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
> copying was expensive, and that for features such as masks or paint with
> the copying would be a burden. But now, based on the experience we have
> 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
> 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop