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

Emanuele Tamponi emanuele at
Mon Mar 24 23:59:34 CET 2008

Hi there,
there is currently a lot of discussion about renaming and rewriting the 
KisBrush-KisPaintOp code... but as it often happens, looking carefully at the 
code it turns out that the current code is completely functional.

Even if I agree with almost everything as it's currently / has been choosen to 
be, I'd like to discuss a bit about where to put the code that transforms the 
footprint of the brush using the current pressure, tilt, et cetera.

Currently, KisBrush doesn't look at KisPaintInformation: it just builds up 
a "plain" footprint. Then, the current paintop applies the transformations, 
for example it enlarge the footprint with the pressure, or darken it... et 
cetera. 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.

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.

Another scenario: since now, only pressure affected the shape of the brush, 
and it affected only its size. But what about "bristled" brushes? We will 
need to code transformation for them too. 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.

Just two scenarios that came to my mind now; there are surely others.


More information about the kimageshop mailing list