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

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