Yet another bug. This time filters vs selections

[Dmitry Kazakov]

>
>  > Probable reasons:
>>> > 1) Heavy filters have bigger footprint
>>> > 2) Internal filters' selections have a big footprint that causes actual
>>> > filter's code run slower.
>>>
>>> I don't understand you here -- the selection we pass to filters is the
>>> same
>>> thing as the selection we pass to bitBlt, so there is no difference in
>>> memory
>>> footprint.
>>
>>
>>
>>
>>> Or do you mean the overhead of using an iterator on the selection?
>>>
>>
>> Yes. Reading an additional piece of memory during filtering creates an
>> overhead.
>> More than that, an additional function call to iterator's operator++
>> breaks cache too (i suppose).
>>
>> Atm, i've finished tests with Invert filter only and got stable result of
>> 20% faster work with bitBlt. Even with "random" shape selections.
>>
> Hmm.. It seems to work with lightweight filters (like Invert) only...
>

Btw, Blur filter doen NOT pay any attention to selections. And i do not know
the way how can it do that. =(

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