Bug 10329

Summary: add support for "recursive" xlib surfaces
Product: cairo Reporter: Allison Lortie (desrt) <desrt>
Component: xlib backendAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: mathias.hasselmann
Version: 1.4.1   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: implement recursion on xlib surfaces (as described)
implement "include inferiors" xlib surfaces
much easier patch
new patch with documentation

Description Allison Lortie (desrt) 2007-03-17 18:36:24 UTC
i'd like support for "recursive" xlib surfaces in cairo.  that is, surfaces that have the following semantics:

1) when used as the destination of a draw op, any child windows that clip the parent are simply drawn over top of

2) when used as the source of a draw op, any child windows that clip the parent are simply taken as part of the source image data

this corresponds exactly to the IncludeInferiors XRenderPicture attribute
Comment 1 Allison Lortie (desrt) 2007-03-17 18:54:46 UTC
Created attachment 9209 [details] [review]
implement recursion on xlib surfaces (as described)
Comment 2 Owen Taylor 2007-03-18 07:50:08 UTC
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.
Comment 3 Owen Taylor 2007-03-18 07:50:36 UTC
Oh, I forgot to say, other than that, the patch looks good to me.
Comment 4 Allison Lortie (desrt) 2007-03-18 09:37:51 UTC
Created attachment 9212 [details] [review]
implement "include inferiors" xlib surfaces

with both suggested changes
Comment 5 Allison Lortie (desrt) 2007-04-02 22:19:13 UTC
poke.

it'd be nice to get this in so that i can document its use in gtk...
Comment 6 Allison Lortie (desrt) 2007-04-08 16:28:42 UTC
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).
Comment 7 Allison Lortie (desrt) 2007-05-18 08:51:38 UTC
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.
Comment 8 Behdad Esfahbod 2007-05-18 08:54:42 UTC
Cool.  I'm quite positive about committing this.  Carl?
Comment 9 Carl Worth 2007-05-18 09:28:41 UTC
(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
Comment 10 Allison Lortie (desrt) 2007-05-22 18:19:03 UTC
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).
Comment 11 Mathias Hasselmann 2007-05-28 00:56:52 UTC
(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).
Comment 12 Allison Lortie (desrt) 2007-05-28 07:51:51 UTC
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
Comment 13 Mathias Hasselmann 2007-05-28 09:23:11 UTC
(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.
Comment 14 Behdad Esfahbod 2007-06-13 15:59:25 UTC
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).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.