Footprint algorithms: in the stamp, or in the paintop?

Cyrille Berger cberger at cberger.net
Tue Mar 25 00:30:21 CET 2008


Hi,

On Monday 24 March 2008, Emanuele Tamponi wrote:
> Currently, KisBrush doesn't look at KisPaintInformation: it just builds up
> a "plain" footprint.
Yes and no.

> Then, the current paintop applies the transformations, 
> for example it enlarge the footprint with the pressure, or darken it... et
> cetera.
No and yes.

KisBrush get a size/rotation that is computed from the 
pressure/tilt/speed/whatever (depending on the paintop, or on the paintop 
parameter).

Darken is unrelated to the KisBrush, it's a transformation of the color. And 
the less KisBrush knows about the color the better, the main reason for that 
is that it use with monochromatic source ( a simple KoColor) or with a paint 
device source.

> So the *generation* of the footprint happens in KisBrush, while its 
> *transformation* is done in KisPaintOp.
> I do not agree with this. I think that we need to make the transformation
> outside KisPaintOp; at least, KisPaintOp should *call* the transformation,
> but do not do it itself.
Yeah that's more or less what is allready done. Except the computation of 
parameters is done in the painting operation, and that's also what give us 
the maximum flexibility.

> Imagine this scenario: I'm working on a painterly paintop, that just
> behaves like a brush but mixes pigment between the brush surface and the
> canvas surface. As it is now I've to copy'n'paste exactly the same code of
> KisBrushOp in my paintop, and then add the mixing stuff.
> This could be avoided by separating the transformation code from the
> paintop and share it between KisBrushOp and KisPainterlyOp.

And I agree that it sucks. But as, the code duplication is mostly parameters 
computation, I really think that the best way is to do this parameter 
computation in a base class. That way if I want to compute the parameters 
some other way in an other paintop, I can do it.

> Another scenario: since now, only pressure affected the shape of the brush,
> and it affected only its size.
You should have a look at the dynamic brush.

> But what about "bristled" brushes? We will 
> need to code transformation for them too.
Hum. Yes. You don't resize a "bristled" brush the same way that you resize an 
autobrush (which are recomputed every time) or an image brush (which are 
scaled)

> With the current infrastructure, 
> those transformation can only be used from *one* paintop - the one that
> implements them.
> Separating the transformation code from the paintop makes them available to
> any paintop.
I really need to know what you call "transformation code". Because, resize and 
rotation is allready done in the KisBrush and Darken is done by a pigment's 
KoColorTransformation. All I see is parameters computation in the paintop.

-- 
Cyrille Berger


More information about the kimageshop mailing list