[pygtk] Trouble with Composited Windows example in gtk.gdk.Window docs

[Nathaniel Smith]

On Fri, May 23, 2008 at 09:00:11PM -0400, Neal Holtz wrote:
> My questions are:
> 
>   1. Why did introducing the the assignment of the pixmap
>      to a local variable ('pm') change things, and what
>      was the cause of that "the target surface has been finished"
>      error?

My guess is that set_source_pixmap does not properly create a
reference to the Pixmap you pass it, so that Python's garbage
collector destroyed the Pixmap, and then cairo got annoyed trying to
use it.  Assigning it to a local variable forces the garbage collector
to keep the Pixmap around.  (That doesn't explain why it's complaining
about the "target" surface, when the Pixmap should actually be the
"source" surface, though.  I'm sure if you wanted to track down the
bugs here in more detail and file bugs then people would be grateful.
set_source_pixmap(Pixmap(...)) should not give an error, you should
file that as a bug already.)

>   2. Why am I still getting the warning about drawing a depth 24 to
>      a depth 32?

Dunno.  Guess you've somehow ended up with windows of different
depths (maybe you explicitly requested that one use a colormap with an
alpha channel?).

>   3. What is the behaviour of this thing supposed to be?  I don't
>      think I get it.  When I mouse over the button, the text
>      disappears.  When I try other mods to the code (i.e., add 2
>      buttons in an Hbox), I seem to get some random dirt written
>      by one of the expose handlers.

I'm not sure what the behavior is supposed to be.  I must regretfully
inform you, though, that you are unlikely to get any particularly
useful behavior from it at all, without falling down a deep rabbit
hole.

1) Pixmap(window) will not give you what you want -- it creates a
new, blank Pixmap that has the same bit-depth etc. as the window you
pass it, not an image of the window.  So it's not useful to pass to
set_source_pixmap anyway; you really want to pass the window itself.
Fortunately this will be fixed in 2.14:
  http://bugzilla.gnome.org/show_bug.cgi?id=491256
and as a workaround you can use
  cr.set_source_pixmap(window.cairo_create().get_target(), 0, 0)
2) Unfortunately, this won't work anyway, because there are a
gazillion different X server bugs that get triggered if you try to use
a window as a render source instead of a pixmap, and have any kind of
non-trivial transformation (e.g., scaling or whatever).  To work
around *those*, you need to use the NameWindowPixmap request in the
Composite extension, which requires writing C code and (in the general
case) playing complex games with X events.
3) But maybe that's okay, because the GTK+ compositing API is
crippled; you can't apply any kind of complex transformation *anyway*.
AFAICT the *only* thing that the GTK+ compositing API lets you do is
make alpha-transparent widgets (bug #495192).

If you want to make the GTK+ compositing API good, then that'd be
awesome; if you just want to play with compositing from Python, then
I gave up and wrote my own API and the code is in 'wimpiggy'
(http://partiwm.org, look for wimpiggy.composite), and that might be a
better place to start; if you decide to back away slowly, then I don't
blame you :-).

-- Nathaniel

-- 
Electrons find their paths in subtle ways.