PS/PDF API Change Proposal: (Re: [cairo] Semantics of transparent objects)

[Keith Packard]

On Tue, 2006-01-17 at 23:19 -0800, Carl Worth wrote:

> Another thing I wonder is whether we shouldn't implement things so
> that a user can request to have destination-alpha rendering even on
> something like win32 where it wouldn't be "natively" supported. That
> seems it would parallel the proposal with the PS backend here, (but it
> might just be setting a nasty performance trap too). However, I
> suppose a similar surface with CONTENT_COLOR_ALPHA should already be
> available (I haven't tested this) and that interface should make the
> performance implications more obvious (the fact that the intermediate
> surface might actually be an image surface rather than any native
> surface type).

So why aren't we doing the same for PS/PDF (that is, expect the user to
create an ARGB similar surface and do the final composite themselves)?

We discussed how to implement this meta-ARGB->meta-RGB composite without
reducing it to creating an ARGB and RGB images and doing the composite
in pixels. 

The advantage here is that our opaque PS/PDF output would be 'normal',
instead of having this unusual case where a surface with destination
alpha ends up implicitly composited on a white background.

The obvious alternative is to require all backends to support both RGB
and ARGB surfaces; the counter argument is that ARGB surfaces on some
backends are unsupported by the native graphics, and that performance
would be terrible as a result.

While some would suggest that I have demonstrated a lack of compassion
for performance sensitive applications, I think this case is relevant
here; pure software rendering vs hardware accelerated compositing is a
huge issue for interactive applications, so we should make performance
compromises evident to applications in that space. For non-interactive
applications, performance can be somewhat secondary to functionality,
which leads us to expose an ARGB surface capability for the PS/PDF
backends (to ease application construction) while not requiring it from
the Windows backend (to ensure applications understand the performance
implications of their actios).   

I just wanted to make it clear why the PS/PDF case is different from the
Windows case, and why doing this same hack for Windows isn't obviously
right at this point.
  
-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060117/22edfec3/attachment.pgp