brushes and brush engines

Boudewijn Rempt boud at valdyas.org
Tue Mar 18 23:03:01 CET 2008


On Tuesday 18 March 2008, Cyrille Berger wrote:

> Well I vote for KisBrushStamp, KisBrushEngine and KisBrushSettings.

I'd prefer KisTip myself -- to minimize the relation between the brush engines 
and the ex-KisBrush type of resource.

KisBrushSettings might better be called KisBrushState since it contains more 
than settings, but also state kept during painting -- like active node, 
pointer event etc.

I hadn't realized that doing this would also entail creating a whole new 
resource type, KisBrushEnginePreset (or, until the renaming is carried 
through, KisPaintOpPreset): that would be a serializible configuration 
containing a paintop id, the xml from KisPaintOpSettings and the xml from 
KisBrush -- if any.

> > * We want to have only one collection of brush tips shared by all
> >   brush engines that use brush tips. Besides, the autobrush brush tip is
> > used outside the brush engines, too.
>
> The only place it's use (outside autobrush) is for creating kernel for
> convolution. And afaik, for this, it would be better to use something else
> (like extending kernel to create those kernel), even if the math is very
> similar (until now I was lazingly using the autobrush function, but I am
> ready to make the needed changes to avoid that use).

That should make life quite bit easier, especially because this way it becomes 
easier to make the various types of brushes, tips, stamps actual plugins.

> > * We'll look more like Photoshop than like Corel Painter after this
> > change.
>
> Is this a bad thing ?

:-P

> > Implementation:
> >
> > I'll have to make some changes in the canvas resource provider,
> > the control box and add gui classes to implement the preset
> > designer/manager. I've got already some code for that.
>
> I agree with Casper, it sounds ok. But it also sounds like a huge
> undertaking, can it wait until after 2.0 ?

It is quite a bit of work, but I'd really like to have it in place before the 
summer of code starts because it brings a lot of sense to our paintop 
interface. I would like to spend tonight and Thursday night on this and see 
how far along I manage to come: then I can decide how much more work it is 
than I'd thought it would be. (Western Easter weekend I intend to dedicate to 
the text shape.)

> It's recreating a color transformation for each stroke, that would be the
> explanation, but that shouldn't be that slow to look like a "hang".

It's pretty bad, really. I'm fairly sure that this is the actual problem, 
though.


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


More information about the kimageshop mailing list