koffice/krita/image

[Dmitry Kazakov]

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

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