Summer of Code

[Matthew Woehlke]

Boudewijn Rempt wrote:
> Well, painting with filters has been possible for ages. I haven't been able to 
> run Photogenics for a long time (it used to work on Linux, but as a binary 
> only package it broke ages ago). 
> 
> However, we do have an architectural issue here. Krita is designed like this:
> 
> KisTool: determines the begin and the end point point of a line that will be 
> painted:
> 
> KisPaintOp: brush engine: completely determines what actually happens between 
> the begin and th end that KisTool told KisPaintOp to paint.
> 
> The key here is "completely". It is impossible to constrain what KisPaintOp 
> does. It needn't even use the composite op or opacity setting in the tool's 
> option widget.

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.

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

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