Yet another bug. This time filters vs selections

[Boudewijn Rempt]

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