Paintops

[Matthew Woehlke]

Boudewijn Rempt wrote:
> 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.

"Many"? Example, please?

>> 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.

That's not a problem... I said "might" because I wasn't sure it would 
work that way or not. *Not* working that way probably makes the most 
sense, honestly, but anyway it's not very important. The point was I 
don't think it's important to combine a non-filter paintop with a filter 
paintop.

-- 
Matthew
Save soybeans! Avoid TOFU! (http://en.wikipedia.org/wiki/Posting_style)