Re: minor fix for GdkPixbuf

[Havoc Pennington <hp redhat com>]

Ramiro Estrugo <ramiro fateware com> writes: 
> I dunno if this is something feasable or not, but one thing you might
> consider is having 2 versions of the capture  function.  One that does
> "smart" clipping, grabs/ungrabs the servers and is documented to be
> slow.  And, another one  doesnt do any smart stuff.  I agree this
> complicates the API and can be confusing.  The reason why I did things
> in  this hacky way was to reuse the gdk-pixbuf conversion functions. 
> Otherwise it would have been simpler to use straight  xlib.

My patch adds gdk_pixbuf_get_from_image() as found in desk guide,
which means you can write your own code to get the image, avoiding all
the clipping and race-condition-avoidance code, but still using the
Hard Bits (the RGB conversion stuff) from GDK in order to convert
image to pixbuf.

Owen was suggesting that we actually put the grab in gdk_image_get()
itself though - if the grab doesn't seem to matter for speed that's
probably feasible.

Remember that the grab only happens if you are actually getting from
an X window; for e.g. nearly all uses of GtkImage, you will actually
be getting the backing store pixmap, which means you don't need to
grab. i.e. gdk_image_get() would only grab if
GDK_IS_WINDOW(src_drawable).

The only time you actually have to get from an X window is for
screenshots and maybe for desk guide thumbnailing - applications
shouldn't ever be doing this assuming they are double-buffering which
is the normal thing. There's thus no need for grabs to draw menus and
icons.

Havoc