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