koffice/krita/image

Cyrille Berger cberger at cberger.net
Sat Oct 3 23:22:40 CEST 2009


On Friday 02 October 2009, Dmitry Kazakov wrote:
> "double-paintdevice" loops:
> 1-st - bitBlt'ing an image in KisLayer::applyMasks
> 2-nd - KisFilter's loop ( src ----filtering----> dst )
> 3-rd - bitBlt'ing in KisMask::apply() to take a selection into account
> 
> "single-paintdevice" loops:
> 1-st - bitBlt'ing an image in KisLayer::applyMasks
> 2-nd - bitBlt'in in KisImage to leave an original copy untouched by a
>  filter (for applying a selection then)
> 3-rd - KisFilter's loop ( src ----filtering----> src )
> 4-th- bitBlt'ing in KisMask::apply() to take a selection into account
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).
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.

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
2) double the number of tiles retrieval (or even mutliply the number of 
retrieval by 2*64 for the current non optimized KisH/VLineIterator)
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

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.

-- 
Cyrille Berger


More information about the kimageshop mailing list