[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-14 10:06:17
Message-ID: ae32c1ef0909140306i1f4830bake8f430d737582edc () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
>
>> On Sunday 13 September 2009, Dmitry Kazakov wrote:
>>> > Btw, Blur filter doen NOT pay any attention to selections. And i do not
>>> > know the way how can it do that. =(
>>> it's probably just a matter to give the iterrators the selection object.
>>>
>>
>> It won't solve the problem of semi-selected pixels (pixels with
>> alpha~128). Such pixels should be filtered with cs->applyAlphaU8Mask()
>> separately. I think it'll be quite complex solution for blur filter.
>>
>>
>> Atm, i insist on using bitBlt after the filtering. This will make filter
>> creation much simplier, especially for filters that are quite complex
>> themselves (like convolution). My tests show the following overhead:
>>
>> when 28% of the canvas is deselected we get only 2% overhead
>> when 53% of the canvas is deselected we get only 13% overhead
>>
>
> when 73% of the canvas is deselected we get only 19% overhead
>
heh... with 95% of the canvas deselected we get only 30% overhead. =)
It seems that 70% of the time is consumed by
KisBrightnessConstrastFilter::createTransformation(cs, config) method, not
by filtering itself. =)
I use filtering rect of size - 500x320px. If we assume, that
createTransformation() is constant time function, then enlarging filter rect
to 1+Mpx will degrade performance much.
I think the following approach can be used:
1) We drop selections from filters and use bitBlt instead
2) In the future, when new tile engine gets activated, we'll optimize filter
application. Filters will be applied tile-by-tile. This means that
rectangles with underlying tiles of selections are not present simply won't
be filtered.
3) Of course, for realization of 2) we have to drop all the constant-time
components from process function (like createTransformation()).
PS:
This approach can create some border-effect-problems, but i guess it has
already been solved in kis_dlg_adjustment_layer.cpp
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<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="im"><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><div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">
<div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; \
font-style: normal;"><div>On Sunday 13 September 2009, Dmitry Kazakov \
wrote:<br></div><div> > Btw, Blur filter doen NOT pay any attention to selections. \
And i do not<br> > know the way how can it do that. =(<br></div>
it's probably just a matter to give the iterrators the selection \
object.<br></div></blockquote></div></div><div><br>It won't solve the problem of \
semi-selected pixels (pixels with alpha~128). Such pixels should be filtered with \
cs->applyAlphaU8Mask() separately. I think it'll be quite complex solution for \
blur filter.<br>
<br><br>Atm, i insist on using bitBlt after the filtering. This will make filter \
creation much simplier, especially for filters that are quite complex themselves \
(like convolution). My tests show the following overhead:<br>
<br>when 28% of the canvas is deselected we get only 2% overhead<br>when 53% of the \
canvas is deselected we get only 13% \
overhead<br></div></div></blockquote><br></div></div>when 73% of the canvas is \
deselected we get only 19% overhead<font color="#888888"><br> \
</font></blockquote><div><br>heh... with 95% of the canvas deselected we get only \
30% overhead. =)<br><br><br>It seems that 70% of the time is consumed by \
KisBrightnessConstrastFilter::createTransformation(cs, config) method, not by \
filtering itself. =)<br> <br>I use filtering rect of size - 500x320px. If we assume, \
that createTransformation() is constant time function, then enlarging filter rect to \
1+Mpx will degrade performance much. <br><br>I think the following approach can be \
used:<br> <br>1) We drop selections from filters and use bitBlt instead<br>2) In the \
future, when new tile engine gets activated, we'll optimize filter application. \
Filters will be applied tile-by-tile. This means that rectangles with underlying \
tiles of selections are not present simply won't be filtered.<br> 3) Of course, \
for realization of 2) we have to drop all the constant-time components from process \
function (like createTransformation()).<br><br></div></div><br>PS:<br>This approach \
can create some border-effect-problems, but i guess it has already been solved in \
kis_dlg_adjustment_layer.cpp<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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic