Yet another bug. This time filters vs selections

[Dmitry Kazakov]

On Fri, Sep 11, 2009 at 10:16 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

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

I've just dropped all the code, connected with selections from
kis_color_transformation_filter.
So i filter a *rectangle* bounding a selection. Then i just bitBlt
interesting area.


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

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.

I've started tests with blur and curves...




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