<br><br><div class="gmail_quote">On Fri, Sep 11, 2009 at 10:16 AM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Thursday 10 September 2009, Dmitry Kazakov wrote:<br>
> I've done some tests and got some curious results on selections inside<br>
> filters.<br>
<br>
</div>I would really like you to be more explicit in explaining what you did. For<br>
instance, did you filter all pixels regardless of selection, or did you skip<br>
totally unselected pixels?<br></blockquote><div><br>I've just dropped all the code, connected with selections from kis_color_transformation_filter.<br>So i filter a *rectangle* bounding a selection. Then i just bitBlt interesting area.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> It turned out that additional bitBlt doesn't cause any considerable<br>
> penalty. On fast lightweight filters (Invert filter) the scheme with<br>
> bitBlt'ed selection works up to 1.8 times faster (need to be proved), on<br>
> heavy and slow filters (like Curves, Levels) the time is almost the same<br>
> (~2% slower at the worst case).<br>
><br>
> Probable reasons:<br>
> 1) Heavy filters have bigger footprint<br>
> 2) Internal filters' selections have a big footprint that causes actual<br>
> filter's code run slower.<br>
<br>
</div>I don't understand you here -- the selection we pass to filters is the same<br>
thing as the selection we pass to bitBlt, so there is no difference in memory<br>
footprint. </blockquote><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Or do you mean the overhead of using an iterator on the selection?<br>
</blockquote><div><br>Yes. Reading an additional piece of memory during filtering creates an overhead.<br>More than that, an additional function call to iterator's operator++ breaks cache too (i suppose).<br> </div>Atm, i've finished tests with Invert filter only and got stable result of 20% faster work with bitBlt. Even with "random" shape selections.<br>
<br>I've started tests with blur and curves...<br><br></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>