boud at valdyas.org
Tue Mar 16 17:40:27 CET 2004
On Tuesday 16 March 2004 15:48, Adrian Page wrote:
> On Tuesday 16 March 2004 10:58 am, Boudewijn Rempt wrote:
> > Maybe it's an idea,
> > if it's too slow, to disable it for the expensive brushes like the pipe
> > brushes or the colour brushes, and just use it for the simple masks?
> Could do. See how it goes once it's properly integrated.
> computeDab() is currently the slow part of the paint procedure, with its
> single pixel writes. That gets hit every time the pressure changes, or each
> dab paint for pipe brushes. I think there's plenty of scope for
> optimisation there.
I've been thinking about introducing a cheaper thing to store small bits of
imagedata in -- without tiles. Once there's a simple way of storing quantums
that has little overhead for pixel-messing, computeDab can become cheap, too.
The only thing that's needed is overload bitBlt to composite these cheap dabs
onto the canvas. And even that is not necessarily a big problem, since the
colour strategies do their bit of work on simple memory buffers of quantums.
> Using valgrind to profile KisToolBrush::mouseMove() with a pipe brush,
> about 80-90% of the time is spent in computeDab(),
That's what I very greatly feared, yes.
> and around 10% in
> compositeCopy() and compositeOver(). The compositing code also has plenty
> of room for improvement, part of which would be using premultiplied alpha
> for the RGBA buffers. We can also replace division by shifts and optimise
> for each channel depth we support.
Premultiplied alpha was one of the things that were already planned when
Patrick began his grand redesign; if at all possible, it's something to
implement before our first alpha.
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop