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

[Carl Worth]

On Wed, 18 Jan 2006 23:07:14 -0500, Owen Taylor wrote:
> But I'm really not very comfortable with the with the idea of a 
> CAIRO_CONTENT_COLOR_ALPHA PS/PDF surface; I have concerns about 
> efficiency, concerns about consistency with the rest of cairo,
> and concerns about utility.

Hi Owen,

I'm glad to have you involved in this debate. Thanks for taking your
time.

>  B) It's good for slicing and dicing objects - cutting one
>     object out of another, and so forth.

Of the use cases you point out, this is the one I'll pick to talk
about, (though there is a more general issue I think).

>                                          This is basically
>     always done in a group rather than on the final destination
>     surface (Because, other than in A) above, we need to
>     end up with an opaque surface in the end, so cutting
>     something out of your destination is a bad idea...)

Since destination-alpha surfaces do exist, code can be written that
does do slicing and dicing on the final destination and not in a
group. And this is one of the scenario I imagined causing a problem. I
imagine it like this:

	* User writes a program to display a "donut" shape achieved by
	  drawing an opaque circle then "cutting out" a smaller circle
	  with an operator such as CLEAR.

	* User directs the same drawing code to a PS surface (without
          destination-alpha semantics) and prints it.

	* User is bewildered to discover that outside the donut shape,
          things are transparent (as expected) but the inside of the
          donut shape is solid blank ink, not transparent.

	* User files bug report against cairo.

What's the answer to give this user? Is it, "Oh, you shouldn't be
drawing like that. Go back and change your rendering operations so
that they work without ever relying on destination-alpha semantics." ?

One might challenge the assumption of my scenario saying that users
probably won't draw things this way, but that seems a rather fragile
basis for deciding the semantics of the imaging model for cairo's
print output.

My desire is that print output from cairo provides output consistent
with what is possible with display output. If there are operations
that are going to be just plain unsupported for print output, then I
would argue they don't belong in display output.

> In the end, the reason why people want to use the PS/PDF model
> is not to produce printouts of the Cairo test cases, but
> to create and print documents; word processor documents, photos 
> of their kids, and so forth.

Not cairo test cases, no, but anything that can be displayed. And
color-only PS output doesn't provide that.

> We're going to have enough trouble producing good high-quality
> output for the normal case where they do that by simply drawing
> objects with OVER, that introducing a whole other code path
> of questionable utility that probably will never be optimized
> seems dubious to me.

It's not an entirely new code path. The necessary change in the code
is quite small. Basically, we just have to adjust the
ps_surface_can_implement_operation_natively to consider the
cairo_content_t value in addition to the operator and source pattern
type, etc.

The existing image fallback paths take care of the rest, and there's
really no difference in efficiency until the user actually uses an
operation that relies on destination alpha.

> And especially without such optimization, the extra parameter
> to cairo_ps/pdf_surface_create() just becomes a FAQ trap. 

Yes, there is a FAQ trap here, I agree. But I think it's limited to
"What's the right value for the cairo_content_t parameter?"

And I'm not sure what the right answer to avoid that is. We could
certainly move the cairo_content_t to an alternate _with_content
constructor (or whatever), but it's still not obvious to me which mode
should be the default.

> For normal uses, CAIRO_CONTENT_COLOR and CAIRO_CONTENT_COLOR_ALPHA
> will give exactly the same result, but CAIRO_CONTENT_COLOR_ALPHA
> will likely be considerably less efficient.

I agree that for many common uses the two modes will be
equivalent. No matter what we do that means it will be easy for users
to have the wrong option set for a while before noticing.

I disagree that supporting COLOR_ALPHA will be less efficient. For
the common uses where the result is the same, I believe the
performance will also be the same.

All I want to be sure of is that when the user does realize that they
are getting the wrong results that we can just say "Pass the other
cairo_content_t value" and allow the user to get the desired result
without changing all of the user's rendering code.

> Plus, I'd argue that CAIRO_CONTENT_COLOR_ALPHA here really
> doesn't mean the same thing here as it does in the rest of the
> API. You say that you think we should be able to create Win32
> surfaces with alpha... you certainly don't mean that you should
> be able to create Win32 surfaces that magically composite
> against white, do you?

I think Keith has provided good justification that PS/PDF are
different enough that there's no need to consider adding COLOR_ALPHA
support to win32, (where, yes, it would be a huge performance trap).

> The final result of drawing to a PS/PDF surface does *not* 
> have alpha, no matter what your best intention.

Of course not. And use cases such as printing to overhead
transparencies are *not* my motivation in this discussion.

>                                                 (Even you print
> to overhead slides, the alpha there is just the color white,
> and has no relation to the alpha of your surface.)

As an aside, Michael Sweet has recently reminded us that there are
media color properties that can be presented in PostScript output and
respected by the downstream print systems. We can certainly support
any color in addition to white for the default background color.

>                                                    What would
> be the analogy elsewhere? If I create a ARGB surface for an
> xRGB X window that doesn't have transparency, then areas I leave
> with alpha < 1.0 come out black not white. for their printer or for
> redistribution. 

I think I would prefer if it were not possible to create an ARGB
surface for a display device that doesn't actually support the alpha
channel. We perhaps don't have the technical means of detecting that
in the X world right now, but we'll probably need that, (applications
will need to know if they can rely on alpha or not).

> As I said at the beginning, I don't object strenuously here,
> but it is a parameter to confuse users, and a code path to
> confuse implementers that in the end doesn't seem useful
> to me, except for making our test cases look more orthogonal
> and consistent. PS and PDF don't have transparency.

And in summary, I don't think the lack of transparency in the final
PostScript output has any relevance here. The point is that the cairo
imaging model does have operations that rely on destination alpha, and
I would like our print output to support the entire cairo imaging
model.

PostScript also doesn't provide for source alpha either, but you
certainly would not recommend we abandon all of our image fallback
plans to emulate source alpha on PostScript, right?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060119/ee267f36/attachment.pgp