Bug 7446

I think the problem here is in the Quartz code, not the fallback code.
The Quartz code *cannot* allow a fallback code to be called if it 
can't provide the facilities that the fallback code needs. (Getting
the relevant area of the destination as an image.) 

Since I very much doubt that all of Cairo's compositing modes can
be natively done in Quartz, you really have to fix the lack of the
ability to get the destination surface.

Owen, it's the source surface that can't be accessed as an image, not the destination surface. But point 
granted, the Quartz backend really should be able to acquire a source surface. I'm working on that right 
now, I have it mostly working--however the solution will have to be OS X 10.4-only, so I'd really like to 
find a way to fix the infinite recursion on 10.3 as well.

Created attachment 6152 [details]
Test case

It's certainly valid to have surface types that can't be used as sources ...
that's the case for window surfaces on any platform, really.

I was pretty sure that the code as it existed in the 1.0.x branch handled that
case, but looking at the 1.1.x it's been significantly rewritten, and is
unfamiliar to me, so I'm not sure if it regressed or it never worked.

Created attachment 6154 [details] [review]
Implementation of _cairo_quartz_surface_acquire_source_image

Here's an implementation of acquire_source_image for the Quartz backend. It
should work for any bitmap image context on Mac OS X 10.4 or later. It should
also compile against earlier versions of OS X. If compiled for 10.4 with
MACOSX_DEPLOYMENT_TARGET=10.3, then it should be weak-linked and can still run
on 10.3.

Created attachment 6155 [details]
Updated test case

Note that the bug as originally reported is still present, even if acquire_source_image works on Quartz. 
This just makes it less likely to be encountered.

(In reply to comment #4)
> It's certainly valid to have surface types that can't be used as sources ...
> that's the case for window surfaces on any platform, really.

I don't think we have that codified anywhere.

There's certainly nothing in the documentation of
cairo_pattern_create_for_surface nor any of the cairo_surface_create functions
about possible failures, (nor even an error status that would be appropriate for
this case).

As far as the issue with window surfaces as source, we have said several times
in discussion that that wouldn't be useful, but we've always left it as a "just
don't do that" issue.

As far as I know, we don't currently have a supported surface backend for which
none of its surfaces can be used as part of source patterns. And I'd like to
preserve that characteristic.

-Carl

PS. I haven't looked closely at the conditions for actually triggering this
bug---I just wanted to reply to this one comment I saw.

We have a long list of issues with windows as source surfaces:

 - There is no guarantee of retention of pixel contents for windows;
   this is OK for output fallbacks, since we only care about getting
   the pixels we are going to draw to (the "interest area"), but drawing
   from an offscreen window to something visible may well produce
   junk.

 - We don't track a useful size for windows. On Windows, we have
   the size only of the interest area (possible empty, have
   we tested the repeat code with a 0x0 surface?) On X, we do have
   the window size, but it allowed to be stale; so transiently, the
   repeat pitch for a fallback operation might be different
   from the pitch of the same operation done via RENDER.

 - I'm pretty sure we don't properly guard all use of windowing system  
   functions that can't handle a window as a source surface; whether
   that is setting the surface as a tile on an X GC, or using AlphaBlend
   on windows.

Some of the above are fixable, some of the above are not fixable. It
seems very much in the spirit of what we do currently, in any case,
for a surface to return UNSUPPORTED from acquire_source_image; the only
reasonable alternative in some cases would be to return a 1x1 transparent
surface, and why should the backend have to do that?

(In reply to comment #9)
> We have a long list of issues with windows as source surfaces:

Yes, I understand that.

> It seems very much in the spirit of what we do currently, in any case,
> for a surface to return UNSUPPORTED from acquire_source_image;

And what do you propose happen after that? There's (obviously) no fallback code
in cairo_surface_acquire_source_image to handle this case. And it's very much
not in the spirit of anything we do currently to advertise any operations as
UNSUPPORTED to the user, (which is why UNSUPPORTED is an internal status value
only, and not public).

That's the point I was trying to make before. I really don't want to start
sprinkling the cairo API with the kind of unreliability that would occur if any
given operation "might not work" in the mind of the user.

-Carl

Well, I'm not sure how not working but not reporting an error gives more
reliability than not working and reporting an error..

But more specifically: if you think that drawing nothing without reporting 
an error back to theuser is OK, then we might as well do that in the wrapper 
code as compared to making backends implement it individually.

Obsolete!