<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
> 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><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></div></blockquote></div>Hmm.. It seems to work with lightweight filters (like Invert) only...<br clear="all">
<br>-- <br>Dmitry Kazakov<br>