All over again - Painterly Paint Operator (or Operation :) ?) and Mixer

[Cyrille Berger]

On Tuesday 11 March 2008, Emanuele Tamponi wrote:
> This is how it's currently, and it's good. But I think that KisBrush can be
> expanded (subclassed?) so that it takes not only the transformation
> parameters, but also the pressure and the "tip type". Then the subclass of
> KisBrush will do its calculation to find the footprint of the brush (the
> dab). This subclass of KisBrush could even not know anything about the
> color, that will be "applied" over the footprint by the paintop. Obviously
> this is completely optional, and we can leave as default behavior of
> KisBrush the addition of color in the dab.

If you do that, it's a completely different type of object than KisBrush. What 
would be the point of inheriting KisBrush then ?

 That said generateMask could take a parameter that could be the "height" (I 
call height the parameter selection the section of the 3D brush), I dislike 
the re-introduction of KisPaintInformation in KisBrush (it still available as 
a parameter of generateMask but only because it's needed to get the same 
behaviour when using gimp's pipe brushes), there is no reason why size 
or "height" should be associated with pressure.

But that doesn't solve the problem of color in a painterly paintop, where I 
expect some interaction between the colors that I have on my pencil and the 
colors on the canvas. If it can be done by providing a KisPaintDevice to 
KisBrush::generateMask, and then do the color interaction at composition 
time, then it should be ok.

On a side note, KisBrush is at the same time an interface and an 
implementation (for "image" brushes), which sucks a little bit. The thing is 
KisBrush(Interface) doesn't do the addition of color to the dab, it's left to 
the implementation, but it is expected that the implementation of 
KisBrush::generateMask (including the one that is implemented directly in 
KisBrush) does the addition of the color.

-- 
Cyrille Berger