Re: Compositing and alpha

[Alexander Malmberg]

> Hello,
> 
> On Mon, 5 Aug 2002, Alexander Malmberg wrote:
> > Recently I've implemented better compositing support in back-art,
> > including most operators in the non-compositerect case. There's a pretty
> > picture of it all at:
> >
> > http://w1.423.telia.com/~u42308495/alex/backart/backart_composite.png
> 
> Great! Is this generated by code that is calling private functions in the
> art backend or by using DPS/OpenStep functions? In the latter case it
> would be nice if you could make this test available. I could use it to
> check ghostscript for bugs or could run it on OPENSTEP 4.2 for reference.

I have a whole bunch of tests like this collected in DPSTest app,
similar to GSTest for gui:

http://w1.423.telia.com/~u42308495/alex/DPSTest-0.5.tar.gz

Basically, some tests set up state (the ones that activate), and some
actually draw (the draw buttons, or draw menu entry), and some do both.
Bundle contributions are welcome! :) (The image test isn't complete
yet.)

The interface uses boxes for layout, so porting might be tricky. Could
be worth fixing to get OS 4.2 results, though.

[snip]
> > 1.
> > Currently, when you render with alpha in back-art, the stuff you render
> > gets blended over the stuff that's already there. Another way of dealing
> > with alpha would be to simply replace when drawing, including the alpha
> > buffer. Some DPS docs I've found seem to imply this. ...
> 
> My experience also shows this. Tests on OS 4.2 and ghostscript show that
> drawing with alpha does not blend, but overwrites color and alpha.
> 
> > ... I'm not sure what
> > mosx does. What should GNUstep do?
> 
> I'm not sure about MacOS X either, but Quartz docs at
> http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Quartz2D/drawingwithquartz2d/qcolor/Using_Transparency.html
> imply that Quartz does blend when drawing with alpha. I think to preserve
> compatibility GNUstep should behave like OS 4.2 when using DPS functions
> and implement MacOS X behaviour in the Quartz like interface.

So we're caught between two alpha models :/. It would be nice to have
some sort of official word about what the ultimate goal for GNUstep is
(Adam Fedor?).

Implementing both at once would be tricky, but a OS 4.2 compatibility
flag would be an option (ie. you'd set some default key for apps that
expect the old behavior).

[snip]
> results of OS 4.2
> can be found here: http://goliat.eik.bme.hu/~balaton/gnustep/testalpha.tiff
> On screen it looked similar to the ghostscript result, but color values
> are very different. I have no explanation, but would be interested if
> somebody has one. (Probably some color correction or halftoning might
> happened as my screen depth is 16 bpp.)

Probably some sort of dithering. Anyway, it definitely isn't blended or
unpremultiplied alpha.

[snip]
> It is implemented in the gslib backend and supposed to behave like you
> described, but I haven't really tested it yet. You could implement it as a
> blending rectfill, so I cannot see why this would be hard with back-art.

It isn't hard, it's just boring. There are a lot of operators, so a lot
of blending functions would be needed to get everything fully optimized.
I'll probably do a working but slower-than-necessary implementation at
first.

[snip]
> GNUstep on the other
> hand expects NSDrawBitmap to do compositing, thus in the gslib backend I
> currently do an Sover compositing for images with alpha. This is
> incompatible with OS 4.2, but consistent with the current GNUstep usage.

This is consistent with blending when drawing with alpha, so I'll do
Sover compositing when I clean up image handling in back-art. Once
again, it would be very nice to know what the plan here is :).

> Regards,
> BALATON Zoltan

- Alexander Malmberg