Footprint algorithms: in the stamp, or in the paintop?
Emanuele Tamponi
emanuele at valinor.it
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.
Emanuele
More information about the kimageshop
mailing list