Sub-pixel positioning

[Boudewijn Rempt]

On Tuesday 16 March 2004 18:47, Adrian Page wrote:

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

Whichever would be easier & faster... I'm betting on a simple data structure 
for small bits of images, but perhaps we need to explore both alternatives, 
and then choose whichever is best.

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

Hah, yes -- but it also means that I messed up when I coded this bit of 
glacial code up first...
 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. 

It was meant to elicit some discussion. The advantages of rendering each layer 
to rgba before layer compositing are clear: it means you can basically 
combine anything with anything, if needs be even, eventually, karbon layers 
or whatever. The disadvantage is that I'm not sure what combining, say, cmyk, 
in rgba space is going to compared to combining as cmyk.

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

Ah -- then there's not much choice, is there -- whoever codes the code gets to 
call the tune.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi