[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Yet another bug. This time filters vs selections
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2009-09-13 11:51:54
Message-ID: ae32c1ef0909130451g435561afr32d76e0298f32c61 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


> > 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.
>
Hmm.. It seems to work with lightweight filters (like Invert) only...

-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

<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>
&gt; Probable reasons:<br>
&gt; 1) Heavy filters have bigger footprint<br>
&gt; 2) Internal filters&#39; selections have a big footprint that causes actual<br>
&gt; filter&#39;s code run slower.<br>
<br>
</div>I don&#39;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&#39;s operator++ breaks cache too (i suppose).<br>  </div> Atm, i&#39;ve \
finished tests with Invert filter only and got stable result of 20% faster work with \
bitBlt. Even with &quot;random&quot; 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>



_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]