Created attachment 9209 [details] [review]
implement recursion on xlib surfaces (as described)

Can I suggest a name change from recursive, to, say, include_inferiors?

include_inferiors is at least (probably a lot more) as descriptive as
recursive, and has the big advantage of being familiar to people who
are familiar with Xlib.

+    /* XXX: and what about this case? */
+    if (surface->owns_pixmap)
+	return;

I'd set the flag so that _get_recursive() returns what you set but
otherwise ignore it... after all, this setting has no effect on a
pixmap in any case.

Oh, I forgot to say, other than that, the patch looks good to me.

Created attachment 9212 [details] [review]
implement "include inferiors" xlib surfaces

with both suggested changes

poke.

it'd be nice to get this in so that i can document its use in gtk...

Comment on attachment 9212 [details] [review]
implement "include inferiors" xlib surfaces

please don't commit this.

i have a better idea (just need to think about it a bit).

Created attachment 10019 [details] [review]
much easier patch

this patch turns on IncludeInferiors for surfaces used as a source and does nothing to modify the semantics of drawing to surfaces.

this is probably what it is like on windows.

Cool.  I'm quite positive about committing this.  Carl?

(In reply to comment #7)
> Created an attachment (id=10019) [details]
> much easier patch
> 
> this patch turns on IncludeInferiors for surfaces used as a source and does
> nothing to modify the semantics of drawing to surfaces.

Thanks for the patch. Here's what's left:

1. Documentation of the change, which is needed at least in the following places:

   a. Commit message content is needed

   b. Probably some sentence in the documentation of cairo_xlib_surface_create or so

   c. A message sent to the cairo mailing list for any feedback.

Put those in place and I don't have any problem with the patch.

-Carl

Created attachment 10072 [details] [review]
new patch with documentation

mailed the list.

commit message:

Create the source xrender Picture of xlib surfaces with IncludeInferiors.

When an xlib surface is used as the source of a draw operation this will cause
the contents of child windows to be included in the source data.  The
semantics of drawing to xlib surfaces are unchanged (ie: draws are still
clipped by child windows overlapping the destination window).

(In reply to comment #7)
> Created an attachment (id=10019) [details]
> much easier patch
> 
> this patch turns on IncludeInferiors for surfaces used as a source and does
> nothing to modify the semantics of drawing to surfaces.
> 
> this is probably what it is like on windows.
> 
Is there a good reason for dropping destination surface support? There are some cases where this could be useful. For instance when drawing guides on top of some UI (as in test cases or UI designers).

if you try to use cairo to draw in this way you will find that your drawing is simply overwritten on the next expose event...

you're better to use the composite support being added to gdk.  see here:

http://bugzilla.gnome.org/show_bug.cgi?id=412882

(In reply to comment #12)
> if you try to use cairo to draw in this way you will find that your drawing is
> simply overwritten on the next expose event...
Yes I know, but that it easy to handle: You just use your expose handler(s) to add an idle handler which actually does the drawing. Proof of concept here (for GdkGC based drawing): http://svn.gnome.org/svn/gtk+/branches/extended-layout/tests/testextendedlayout.c

> you're better to use the composite support being added to gdk.  see here:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=412882

Composite desktops are not the default yet and considering all the driver problems we have on X11 I doubt they will become the default quickly. So 
IncludeInferiors drawing is very usefull still.

commit 0c5d28a4e5ce5e4dd72c0f416ce5e960e92b808b
Author: Ryan Lortie <desrt@desrt.ca>
Date:   Wed Jun 13 18:59:22 2007 -0400

    [xlib] Create source xrender Picture with IncludeInferiors
    
    When an xlib surface is used as the source of a draw operation this
    will cause the contents of child windows to be included in the source
    data.  The semantics of drawing to xlib surfaces are unchanged (ie:
    draws are still clipped by child windows overlapping the destination
    window).