<br><br><div class="gmail_quote">On Fri, Oct 2, 2009 at 6:00 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">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 class="im">On Friday 02 October 2009, Dmitry Kazakov wrote:<br>
<br>
> It depends on a type of a bug inside convolution painter. If it reads out<br>
> of dst device, then we'll get the same border-effect problem that i have<br>
> been fixing for about a month. If it just uses dst as a default value,<br>
> it'll work, but we can get even more subtle problems in the future, like a<br>
> difference between changeRect of a filter and rc-value transmitted to the<br>
> decorateRect() function.<br>
<br>
</div>Since originally the paint device we were writing to was empty, that shouldn't<br>
matter. Most filters will overwrite everything, for the others it won't<br>
matter, should it?<br></blockquote><div><br>Do you mean that for most of the filters this bitBlt() is simply a waste of time, right? ;)<br><br>We do already have several bitBlts during one merge operation, i think this one is superfluous.<br>
If a filter doesn't want to write to some area he should declare this with changeRect() function, but not just not write there.<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> damn!<br>
<br>
Please work from a basic assumption of competence in the rest of the team,<br>
i.e., assume we know what we are doing with the code we have been working on<br>
for years. I'd like this project to stay a friendly place.<br></blockquote><div><br>Sorry. I was wrong.<br><br>I just want Krita's code to be clean and understandable. And i don't want to see any crutches there. I think if some (old) code is broken it should be fixed or disabled. And we mustn't break any new code too, only for the reason of "giving a crutch to the old one".<br>
I'm continuously trying to explain this idea... And it seems that i fail... :(<br><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 class="im">
> Well, Boud, isn't it easier to fix a bug in convolution painter than to<br>
> create a garbage from our KisLayer/Mask code?<br>
<br>
</div>No, definitely not. I took a look at the code of the convolution painter and<br>
couldn't find any reason for this behaviour.<br></blockquote><div><br>Have you got the proof of wrong behavior of convolution painter?<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Besides, this commit makes the way the filter mask applies filters consistent<br>
with the way the manual filter application works and so offers a better<br>
starting point for refactoring after the release.<br></blockquote><div><br>hmm.. What do you mean by "manual filter application"? I thought if we apply a filter directly through Filters-menu they are added as a TemporaryMask and merged to the layer then, aren't they?<br>
<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 class="im">
> PS:<br>
> I simply can't understand, why are you going to fix KisLayer and KisMask,<br>
> if you know exactly that real problem is inside KisConvolutionPainter?<br>
<br>
</div>I do not know what the problem is in the convolution painter.<br></blockquote><div><br>=)<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 class="im">
> I don't understand something, do i?<br>
<br>
</div>Besides, there is nothing in the api of KisFilter that explicitly declares<br>
that filters always need to write all pixels, changed an unchanged to dst, so<br>
dst should be prepared with a copy of src.<br></blockquote><div><br>Quite illogic, i think. Every process-unit has in-point and out-point. It reads from in- and writes to out-point. And no pre-assumptions.<br><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Whether that is a good api or not, I don't have an opinion about: I'll let you<br>
and Cyrille discuss that. We have had a single-paint device api before, and<br>
that didn't work out either.<br></blockquote><div><br>I don't think it's good to have one, especially if we continue using bitBlt for selections.<br>In such a case we'll have four loops through entire rc instead of three.<br>
<br>"double-paintdevice" loops:<br>1-st - bitBlt'ing an image in KisLayer::applyMasks<br>2-nd - KisFilter's loop ( src ----filtering----> dst )<br>3-rd - bitBlt'ing in KisMask::apply() to take a selection into account<br>
<br>"single-paintdevice" loops:<br>
1-st - bitBlt'ing an image in KisLayer::applyMasks<br>2-nd - bitBlt'in in KisImage to leave an original copy untouched by a filter (for applying a selection then)<br>3-rd - KisFilter's loop ( src ----filtering----> src )<br>
4-th- bitBlt'ing in KisMask::apply() to take a selection into account<br><br> </div></div><br>-- <br>Dmitry Kazakov<br>