koffice/krita/image

[Boudewijn Rempt]

On Friday 02 October 2009, Dmitry Kazakov wrote:

> It depends on a type of a bug inside convolution painter. If it reads out
> of dst device, then we'll get the same border-effect problem that i have
> been fixing for about a month. If it just uses dst as a default value,
> it'll work, but we can get even more subtle problems in the future, like a
> difference between changeRect of a filter and rc-value transmitted to the
> decorateRect() function.

Since originally the paint device we were writing to was empty, that shouldn't 
matter. Most filters will overwrite everything, for the others it won't 
matter, should it?

> damn!

Please work from a basic assumption of competence in the rest of the team, 
i.e., assume we know what we are doing with the code we have been working on 
for years. I'd like this project to stay a friendly place.

> Well, Boud, isn't it easier to fix a bug in convolution painter than to
> create a garbage from our KisLayer/Mask code?

No, definitely not. I took a look at the code of the convolution painter and 
couldn't find any reason for this behaviour.

Besides, this commit makes the way the filter mask applies filters consistent 
with the way the manual filter application works and so offers a better 
starting point for refactoring after the release.

> PS:
> I simply can't understand, why are you going to fix KisLayer and KisMask,
>  if you know exactly that real problem is inside KisConvolutionPainter?

I do not know what the problem is in the convolution painter. 

> I don't understand something, do i?

Besides, there is nothing in the api of KisFilter that explicitly declares 
that filters always need to write all pixels, changed an unchanged to dst, so 
dst should be prepared with a copy of src.

Whether that is a good api or not, I don't have an opinion about: I'll let you 
and Cyrille discuss that. We have had a single-paint device api before, and 
that didn't work out either.

-- 
Boudewijn Rempt | http://www.valdyas.org