Paintops, was: Summer of Code

[Boudewijn Rempt]

On Monday 24 March 2008, Matthew Woehlke wrote:

> Maybe this is being over-engineered. I guess what I would like to see
> is, we have KisTool (KisStrokeTool?) that determines the stroke, the
> stamp/tip/whatever (KisPaintTool?) that takes the stroke (preferably in
> real time, of course!) and decides what pixels actually get "paint"
> along the stroke, and then the Op (KisPaintEngine? KisPaintOp?) that
> decides what to do based on that set of pixels. Some types of "paint"
> would expand the mask from the s/t/w to simulate "bleeding", "wetness",
> etc.

That breaks when you consider that there are many algorithms that aren't 
interested at all in a set of pixels -- where the mask of a stroke is simply 
irrelevant.

> The point: for filters (and "digital paint"), you use the mask exactly
> as you get it from the s/t/w. If you want/need bleeding when painting 
> with a filter, use a filter layer and paint on the mask (but now you can
> use ink, watercolors, etc, on the mask...). Painting with a filter would
> be quite different from painting the mask of a filter layer, because
> overlapping strokes apply the filter multiple times (even overlapping
> segments of a single stroke might do this), and of course you are
> directly manipulating a layer...

Well, it doesn't work that way: the dabs of a stroke may overlap, but the 
freehand filter paint tool in 1.6 cleverly gives the filter the old (pre-undo 
state, from before the stroke began), so the effect you describe doesn't 
happen. Give it a try. Of course, the second stroke does apply the filter 
again. The filter paintop in trunk does the same: give it a try with the 
invert filter.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi