[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 12:31:22
Message-ID: ae32c1ef0909130531i74ebb55ax44d4f9b6c27e6d8e () 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...
>

Btw, Blur filter doen NOT pay any attention to selections. And i do not know
the way how can it do that. =(

-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

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

</font></blockquote></div><br>Btw, Blur filter doen NOT pay any attention to \
selections. And i do not know the way how can it do that. =(<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]