Footprint algorithms: in the stamp, or in the paintop?
mw_triad at users.sourceforge.net
Thu Mar 27 21:46:58 CET 2008
emanuele at valinor.it wrote:
> But, as said on IRC, this design proposes another thing that should be
> discussed and makes the difference a bit bigger.
> Now, we use manipulator to retrieve the "final" stamp that will be
> handled, if needed, by the paintop. The fact is in the current code,
> the "part" of the manipulator is done by single paintops:
> 1) KisBrushOp "manipulates" the source stamp to get the behavior of a brush
> 2) KisPenOp "manipulates" it in another way
> 3) KisBidiOp will manipulate it in still another way
> N) Each KisPaintOp manipulates the source stamp as it wants.
> This has the drawback that each manipulation algorithm is tied to a
> particular paintop instead of being separate from it, that's why the
> idea of the manipulator has come.
...except that I'd rather have KisBrushStamp (the natural bristle brush,
mind), KisDigitalStamp, KisPixmapStamp, etc :-).
But maybe this is just me complaining about the name "manipulator" (if a
stamp is a data class and not a code class as I previously understood).
This looks like maybe it is the case from the pseudocode?
> What I propose is this:
> 1) Make the manipulation, as said before, separate from the paintop
> and just "retrievable" if needed.
> 2) Introduce a KisDrawingOp, that just takes the manipulated stamp and
> draw it onto the canvas.
> 3) Keep KisPenOp and KisBrushOp, if needed, to give more control on
> the manipulations (but I think that they can be completely substituted
> by manipulators + KisDrawingOp + eventually KisDynamicOp)
> 4) From now on, KisPaintOp will not handle manipulations of the stamp,
> it will handle things like bidi operations, colorsource generations
> and so on.
Yup, exactly what I proposed...
Or to reply to "This way, all paintops can access all manipulators. This
way, we can have just *one* paintop that just paints: it uses the
current manipulator to paint natural brush footprints, autobrushes, gimp
brushes, and so on"; yes, yes, /yes/...
Maybe it would make sense to explicitly exclude colored footprints from
this, or to move pigment color explicitly into the stamp/dab/whatever
(hmm, might work) but pigment properties stay in the paintop... except
that means nothing to filter paintop, etc.
Honestly, I don't see colored stamps making sense with natural media
(and they don't apply at all to natural airbrush, bristle brush, etc),
so I think I vote we leave that as-is, but have everything else as
paintop(pigment, stamp(toolpath)). (Recall that stamp contains anything
from toolpath we need.) So we do some of each; leave the current
"digital brush" alone for now, but build the natural-media brushes with
this model. Later we can make a "digital" stamp that works with
autobrush, pixmaps, etc, but without color.
That said, if this is coming out of your posterior then you should
consider your diet. -- Richard Moore, in response to Aaron Seigo's
stated source of suggested enum values.
More information about the kimageshop