Yet another bug. This time filters vs selections
Boudewijn Rempt
boud at valdyas.org
Fri Sep 11 08:16:52 CEST 2009
On Thursday 10 September 2009, Dmitry Kazakov wrote:
> I've done some tests and got some curious results on selections inside
> filters.
I would really like you to be more explicit in explaining what you did. For
instance, did you filter all pixels regardless of selection, or did you skip
totally unselected pixels?
> It turned out that additional bitBlt doesn't cause any considerable
> penalty. On fast lightweight filters (Invert filter) the scheme with
> bitBlt'ed selection works up to 1.8 times faster (need to be proved), on
> heavy and slow filters (like Curves, Levels) the time is almost the same
> (~2% slower at the worst case).
>
> 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?
> More than that, the selection that is applied inside filters - is a
> "discreet" selection, but bitBlt'ed one is normal 256-grade selection.
>
> I got these results on a rectangular selection.
> And they should be proved one more time. I'll do it tomorrow.
--
Boudewijn Rempt | http://www.valdyas.org
More information about the kimageshop
mailing list