Footprint algorithms: in the stamp, or in the paintop?
Emanuele Tamponi
emanuele at valinor.it
Thu Mar 27 21:18:41 CET 2008
As I already said on IRC, I'd like to see another thing added, and one
changed. Boud's mail is great: he's done a complete overview of the
architecture, and my 2 cents are that I almost completely agree with it.
But:
1) I intended KisPaintOpManipulator as a way to select the current way dabs
are manipulated. I mean that, exactly as we now have a paintop selector, a
brush selector, we should have a "manipulator" selector too.
All the code that manipulates the dab and generates the final "footprint" to
be used from a paintop should go there, in the Manipulator. This way, all
paintops can access all manipulators.
2) 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: it just takes the current brush and passes it to the
current manipulator. Then it bitBlts the final footprint to the canvas.
3) A pratical difference from this and the paintop-using-paintop approach?
3.1) paintop-using-paintop:
KisCloneOp::paintAt(info)
{
footprint = otherPaintOp->executeOp(info) <--- slow, with a bunch of
unneeded steps.
doMyOwnThings();
bitBlt(footprint to canvas);
}
3.2) paintop-using-current-manipulator:
KisCloneOp::paintAt(info)
{
footprint = currentManipulator->footprint(currentBrush,info); <--- does
just what it's needed.
doMyOwnThings();
bitBlt(footprint to canvas);
}
As you see, not a very great difference in the code (but I wonder how exactly
you can use a generic paintop inside another...), but 3.2 is clearly faster
at runtime.
Emanuele
More information about the kimageshop
mailing list