Re: houston, we have a problem- 2.10 showstoppers

[Federico Mena Quintero <federico ximian com>]

On Mon, 2005-02-28 at 23:23 +0100, Vincent Untz wrote:

> Matthias has a nice explanation of what is possibly happening:
>   http://bugzilla.gnome.org/show_bug.cgi?id=146075#c89
> 
> I'm not sure it explains why the patch [1] works around the problem,
> though.
> 
> [1] http://bugzilla.gnome.org/attachment.cgi?id=34858&action=view

It doesn't really fix the problem, although gdk_drawable_copy_to_image()
does a server grab.  It will still not be reliable because you are
getting the pixmap ID and then the image data in a non-atomic fashion:
the code doesn't even check for the returned image being null.

You need to

0. [receive notification from the server that the _XROOTPMAP_ID property
changed]
1. grab the server
2. get the value of _XROOTPMAP_ID
3. transfer the pixmap to a pixbuf
4. ungrab the server

>From doing a quick read of panel-background-monitor and its callers, I
saw a few ugly things.  The entire server-side pixmap background gets
exploded into a client-side pixbuf.  Subsequently, subpixbufs get
processed from the latter.  This uses a lot of memory!  Think of a
Xinerama display: the panel will allocate as much memory as is needed to
hold an image that covers all the screens.  This huge image should only
be stored *once* in the X servers.  Apps like the panel that need to do
evil hacks to composite stuff on top should just fetch the regions they
need.

The panel knows which regions will need compositing hacks (translucent
panels and the notification area).  It should only hold auxiliary
pixbufs of that size; definitely not something as big as the whole
screen.

So, ideally, the above should be:

0. get a PropertyNotify event
1. grab the server
2. get the value of _XROOTPMAP_ID
3. for each panel area that requires compositing:
   - transfer a little region from the server-side pixmap to the 
     panel-side pixbuf
4. ungrab the server

  Federico