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

Emanuele Tamponi emanuele at
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.

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:

    footprint = otherPaintOp->executeOp(info) <--- slow, with a bunch of
                                                   unneeded steps.


    bitBlt(footprint to canvas);

3.2) paintop-using-current-manipulator:

    footprint = currentManipulator->footprint(currentBrush,info); <--- does
                                           just what it's needed.

    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.


More information about the kimageshop mailing list