Patch for smudge

[LukasT.dev@gmail.com]

On Thursday 23 September 2010 07:41:38 JL VT wrote:
> Hello Lukas. I gave your patch thorough testing (twenty minutes
> stroking the canvas, plus reading the source, making this e-mail and
> preparing the images, compiling to the lastest version of Krita, etc).
> 

What can I say...Thanks, dude! You rock&roll! 
http://www.youtube.com/watch?v=oHg5SJYRHA0

> From a tester's point of view, this change is very cumbersome. Please
> try to make it such that the "fading time*" of the brush is similar to
> the previous one, ~50% faster at most. It currently feels like the
> brush fades more than twice (maybe trice?) as fast as before, and with
> certain rate settings it basically vanishes instantly.

It is quite complicated problem. Have you got solution or idea how to fix it?
 
> > 8. Have some candies
> 
> Did all that, with candies included.

Wonderful!

> I observed artifacts in both cases.
> 
> Prepatch:
> --Applying the brush on partly-transparent pixels darkened them too
> much (consistent with bug report).

Darken is something different. They became opaque, right? Not darken.
Darken is other composite mode. Or really darken like more black?

> --The stroke starts with white pixels inside the red blot when using
> the copy composite op, this was bad.

> Postpatch:
> --Problems persist with the copy composite op, there still are white
> pixels inside the red blot when the dab resizes mid-stroke (example:
> using stylus). (Upside: this problem is fixed when using just the
> mouse).

It actually should add transparency. I'm surprised.

> --New problem with copy composite op: OUTSIDE the red blot, a
> completely unexpected black smudge appears. This problem is less
> obvious when using a tablet, but completely obvious with the mouse.
> --With the normal composite op this works pretty well and as expected.

This is weird problem. We have similar darkening in the deform brush.
The black smudge does not appear in rgb 16-bit scRgb linear. Maybe some gamma 
correction has to be added for rgb8? 
 
Don't we have some bug in rgb8 colorspace then?

> The small red square inside the stylus stroke using normal composite
> op is EXPECTED, this was discussed earlier with Cyrille Berger and
> there's some comments on the commits (I think I should have documented
> our discussion). To avoid that artifact, simply reduce the spacing
> during the stroke.

Ah, I did not know that it was expected. How do you reduce the spacing during 
the stroke?

> Trying to make that "artifact" disappear for all cases is very tricky.
> We went for a compromise that optimizes speed. Also, this is only
> visible when the dab varies size during a stroke (specially when it
> grows quickly). Otherwise it is indistinguishable.

Question is if we do not want to throw away the size change for smudge.
 
> I also spotted a silly BUG related to SELECTING composite ops:
> --Pick the smudge op.
> --Pick the copy composite op.
> --Then switch to the pixel brush using the hotkey approach (right
> click or middle click of the mouse?).
> --You'll see that the copy composite op is selected in practice (paint
> with it), you'll also see that the name of the composite op doesn't
> appear on the list (it shouldn't be selectable in the first place!).

To http://bugs.kde.org please. Could you look at this boud? Or if busy, put it 
on my Action Plan III.
 
> > It has some blocky effect (also visible before) but that is not important
> > now, I will be important when we decide to go this path.
> 
> The blocky effect shown in the attachment?. It only happens with the
> copy composite op active (I tried normal, overlay, multiply, copy,
> darken and lighten).
> I think the bug lies probably somewhere around KisPainter or the copy
> composite op. I don't think it's inside the smudge op itself.

Yes, there might be problem with composite copy 2 and KisPainter. 
I will write simple test to bit blt black rect on white rect using 
KisMaskGenerator to see what happens.
 
> > I did not managed to test it yet though.
> 
> Do anything that preserves the old "fading time" of the brush. And
> solves the problems presented here. Also, if you reach a satisfactory
> solution, please document the changes in the code (change the part
> that describes the algorithm, for example).

I don't see any idea for solution here. Fix the bugs! does not help me. 
The problem is complicated. There is no such a thing like specification for 
smudge so it is hard to solve it. I studied GIMP code a little, but I was not 
able to understand it. 

Do you know any other open-source projects that have smudge?
Move in deform brush behaves somehow similar but that is really different 
algorithm behind.

You did great job. Great testing! I think you deserve some more candies.
Just ping me shortly before the Krita sprint, I will buy some for you.