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