Summary: | add support for "recursive" xlib surfaces | ||
---|---|---|---|
Product: | cairo | Reporter: | Allison Lortie (desrt) <desrt> |
Component: | xlib backend | Assignee: | 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
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). |
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.