Sub-pixel positioning

[Adrian Page]

On Tuesday 16 March 2004 4:40 pm, Boudewijn Rempt wrote:
> 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.

That sounds like a reasonable idea. The alternative is to use the tile 
manager's read/WritePixelData to move the data around, which would be a big 
improvement too. The overheads involved with setting one pixel at a time is 
what's really killing computeDab.

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

I see that as a good thing, because it's clear we can improve that a great 
deal with relatively little effort. Those are the best kind of 
bottlenecks. :-)

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

It's quite a simple change, especially if we're going to turn CMYK into RGBA 
before compositing, as mentioned in the alpha plan. Exactly how alpha 
interacts with non-RGB colour spaces and compositing is a bit unclear, or at 
least, requires some thought. However, once we're in RGBA land, it's easy 
going. I don't see any problem with doing this before the alpha, and I would 
suggest it be done before any more of the compositing functions are fixed, as 
they're simpler in premultiplied form. I'll happily volunteer to do this. :-)

Adrian