Re: minor fix for GdkPixbuf
- From: Ramiro Estrugo <ramiro fateware com>
- To: Tim Janik <timj gtk org>
- Cc: Havoc Pennington <hp redhat com>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: minor fix for GdkPixbuf
- Date: Wed, 27 Jun 2001 01:37:10 -0700
Tim Janik wrote:
>
> erk. ok two things:
> 1) if you grab the server, mention it in the docu because that makes things
> slow and people shouldn't use it in a loop. (though it's probably the
> right way to do things)
> 2) deskguide won't be able to use it for snap-shooting with server grabs.
> however, i don't see deskguide as enough for a reason to destabelize
> gdk's common code path, so i'd apprechiate any pointers as to what you
> improved over deskguide's shooting code, in order to back-merge these
> things.
>
>
This is what I had to do with the current gdk_pixbuf_get_from_drawable()
to get it to always work - in a loop amongst other extreme conditions:
http://cvs.gnome.org/lxr/source/eel/eel/eel-gdk-pixbuf-extensions.c#1350
This is evil stuff. I have some test programs that trigger the race
conditions. As explained in the code above, I do 2 things to make it
work. 1) handle the X protocol errors and 2) prevent gdk-pixbuf from
doing "smart" clipping - by "pretending" the GdkWindow is a GdkPixmap,
for which there is not geometry clipping. This second hack prevents one
type of race condition, but triggers criticals in
gdk_pixbuf_get_from_drawable().
I tried changing it to grab/ungrab the server before and after. The
performance change is something you can probably mesure, but not
something you can feel. However, I still see the x protocol errors
(BadMatch)
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.
Since gtk widgets are now double buffered, this whole hacky mess might
be moot anyway.
-re
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]