Sub-pixel positioning

[Boudewijn Rempt]

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