brushes and brush engines

[Cyrille Berger]

Hi,

On Tuesday 18 March 2008, Boudewijn Rempt wrote:
> Ok... This started because I wanted to clean up the tablet settings
> for the brush/smudge paintop a biti and started coding an extensible
> paintop settings dropdown to replace the current size/opacity/darken
> toolbar. Then we discussed confusing naming on irc and I suddenly hit
> by a flash of lightning.
>
> Current situation:
>
> * KisBrush and friends: determine the "tip", "stamp", "footprint" or
>   "dab" for some paintops. There is always one active KisBrush, even
>   though the paintop may not use it at all. Brushes are selected from
>   a tabbed drop-down from a toolbar.
>
> * KisPaintop: these are the actual brush engines. Krita can have many
>   different brush engines. Some use brushes, others are procedural.
>   Paintops can have settings that can be saved and loaded, kind of
>   presets, but that are currently not visualized in the gui. Paintops are
>   selected from a combobox and the settings are visualized in a toolbar.

Well I vote for KisBrushStamp, KisBrushEngine and KisBrushSettings.

> Difficulties:
>
> * a unique graphical representation of a preset for the toolbox:
>   perhaps brush engine icon + a small stroke? That would make the present
> buttons fairly wide.  And I think it's essential to show more than one
> brush preset at one time in the toolbar.


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

> * We'll look more like Photoshop than like Corel Painter after this
> change.

Is this a bad thing ?

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

> By the way:
>
> It looks like the "hang" when using darken and the tablet is caused by
> the darken color transform somehow being really, really slow

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".
-- 
Cyrille Berger