Brush tool

[Boudewijn Rempt]

On Sun, 18 Jan 2004, Patrick Julien wrote:

> On January 17, 2004 10:02 am, Boudewijn Rempt wrote:
> > A little more finegrained notify, and the brush tool now is actually
> > usable. It's not as good as the gimp's brush tool -- circles tend to become
> > a little angular, but it's good enough for now.
>
> Are you sure the Gimp brush doesn't draw directly to the screen.  I.e. draw to
> both the tiles and the widget.  Then, when the screen is invalidated, it is
> redrawn from the tiles.

Fairly sure... It's hard to read the code -- but it doesn't look like it.

> Setting the pixels one by one in the dab isn't probably helping you.

On the other hand, that only happens one, when the mousebutton is first pressed,
so it's unlikely to be much of a problem. But I'm now trying to move the painting code
a bit lower in the stack -- have KisPainter retrieve the brush mask, and have the
colour strategy composite the mask directly onto the tiles with the right colour.

>
> The brush tool seems to ignore that the brushes aren't limited to being black
> and white.
>

That's the brush mask code that does that -- I have noted somewhere in kis_alpha_mask
that that's still a problem :-). I'm not sure how to solve that in the most elegant way.
I mean, I can add a kind of capability marker and read that to see what should happen,
an enum or something like that, but that still doesn't sound to good.

> The notification system in Krita, as stated previously, still needs to be
> optimized.  You see, when drawing, we still need to traverse the entire
> sequence of tiles to actually know which we need to redraw.  We need to
> complement this we an actual dirty tile list.  When we mark a tile has dirty,
> it needs to be placed on this list, then when redrawing, we no longer need to
> over every single tile to determine if it's dirty or not.

Well, any optimization here will automatically help my brush tool, wouldn't it :-)?

>
> The string you pass into KisPainter::beginTransaction() needs is user visible,
> hence it needs to be guarded by the i18n macro.
>

Okay -- done..

> In any case, I would think that other programs like gimp draw on the widget
> first, for example in mouse move, but only use the tiles to redraw either on
> damage or mouse release or something equivalent.
>
> If I use Gimp here a second or two, when I use the brush, I can see the
> changes in real time, but the little icon preview doesn't get updated until I
> let go of the mouse button.  This doesn't prove, but certainly supports my
> theory of not using tiles when there is too much activity.
>

I can certainly try that -- but it would be some work I'm going to postpone until
I've got pressure sensitivity and animated brushes working. It would entail converting
every dab to a QPixMap and bitBlting that onto the canvas, after scaling, of course,
and in the meantime still compositing the dab onto the tiles. I would prefer, for the moment,
if the notification system could be optimized :-). Not sure how to do that, though.

In any case, painting feels pretty good already, if I'm not at the same time
compiling KDE 3.2 (which seems to have fixed the kimgio and remote X issue, by
the way; perhaps also the kimgio bugs on ppc. Not that I have noticed much
speed difference between kimgio on my 1ghz pc and Qt's QImage->QPixmap method
on my 500Mhz powerbook...).

Okay, I'm home for at least a week with pneumonia, so I have plenty time for
hacking when I don't sleep. These are my plans:

1. Move paint/paintline into KisPainter
2. Move compositing of alpha mask with current colour to colour strategy (perhaps,
   if it turns out to be a useful speedup).
3. Retrieve the right alphamask size from the brush for the current stylus
   pressure (I alread pre-create the masks, that's done).
4. Write a loader for the Gimp's animated brushes
5. Write a nextMask() or something like that for the animated brushes.
6. Use that in KisPainter.
7. Whatever grabs me next...

I'm not sure how far I will come, and I will regularly commit along the
lines.

There are also some points I am fairly sure I will not solve soon: brushes should be
positioned with sub-pixel accuracy, and that means shifting the alpha mask a bit. This
gives the neat antialiased lines of Gimp's brush tool, what we have now is more akin
to Gimp's pen tool. The brush tool still doesn't have a settings dialog, and coloured
brushes, i.e. brushes that are not simply an alpha mask for a colour, won't be supported
for some time.