We are getting seg faults on our Solaris platform at work when we use
the blit API in GTKAgg. This has been going on for a while, and I
don't know if it is in our pygtk version, or what. The line that is
causing the crash is in src/_gtkagg.cpp
GdkDrawable *drawable = GDK_DRAWABLE(py_drawable->obj);
But rather than spend any more time trying to track that down, I
decided to try and remove the gtk extension code entirely, which would
be a great help for building mpl and distributing binaries. I feel
like I am close, but something is still not clicking (at least on my
platform).
I'm attaching an svn diff in case anyone has some ideas -- basically,
it removes the use of agg_to_gtk_drawable in
backend_gtkagg.FigureCanvasGTKAgg.blit and replaces it with gdk
pixmap/pixbuffer calls. If anyone has any ideas, please let me know.
Attached also is the example code I am using to test. Strangely, the
agg buffer seems to be updating internally but the gtk window is only
updating when I hover my mouse over it, and then only once until I
activate another window and then re-hover over the mpl animation
window.
Thanks for any help!
JDH
diff.out (6.6 KB)
animation_blit_gtk.py (1.51 KB)
OK, this was an example of how writing the email for help solves the
problem. As soon as I described the strange updating behavior, it
triggered my memory about the expose event code in backend_gtk and
when I took a look at that I realized I need to draw to the window and
not the pixbuf as we do in _render_figure. The revised diff is
attached.
So this email now is a patch review request, and importantly, can we
get rid of all gtk extension code? There is now no need for
_gtkagg.cpp, and the only other piece is src/_backend_gdk.c which
provides pixbuf_get_pixels_array. If we could get rid of this, which
is used for images and mathtext in the GDK backend, it would be a big
win for compilation and distribution. Ideally, I would like to not
compile anything against a GUI, but so far we haven't been able to
figure out a way around TkAgg. But removing GTK compile time
dependencies would be a good start.
If you are familiar with agg and/or gtk/gdk internals, please take a
look at my updated patch. I am not double buffering as we are in
_render_figure, which seems appropriate for animation. I am actually
a little confused about why we need so many buffers in the main draw
pipeline -- we have the agg buffer, the gtk pixbuf, the gdk pixmap,
and the gdk window. Does anyone recall why we don't render directly
from the pixbuf to the window here? My guess is that it is to handle
the expose event in backend_gtk efficiently, but we should be able to
do this from the pixbuf directly to the window.... Or perhaps I'm
missing something.
I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
think we should consider disabling default builds of _backend_gdk.c
(they could be enabled by a config option if we can't find a python
replacement for pixbuf_get_pixels_array)
JDH
diff.out (6.53 KB)
animation_blit_gtk.py (1.51 KB)
···
On Tue, Nov 9, 2010 at 2:25 PM, John Hunter <jdh2358@...149...> wrote:
Attached also is the example code I am using to test. Strangely, the
agg buffer seems to be updating internally but the gtk window is only
updating when I hover my mouse over it, and then only once until I
activate another window and then re-hover over the mpl animation
window.
John,
Based on a very superficial look, I suspect we could eliminate pixbuf_get_pixels_array by using the function Overview — PyGObject.
Eric
···
On 11/09/2010 11:03 AM, John Hunter wrote:
On Tue, Nov 9, 2010 at 2:25 PM, John Hunter<jdh2358@...149...> wrote:
I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
think we should consider disabling default builds of _backend_gdk.c
(they could be enabled by a config option if we can't find a python
replacement for pixbuf_get_pixels_array)
Nice find -- this does the trick. I was able to plug it into gdk
draw_image and draw_mathtext fairly painlessly. I've now removed all
the gtk compile time dependencies in the attached patch against svn
HEAD. Because this is a major change, I'm going to hold off
committing it to give you all a change to review and test, and I'll
test some more on a different platform when I get home. But on
solaris python2.4, I have animations with blitting in gtkagg, images
and mathtext in GTK/GDK, so this is looking pretty good so far (all of
this was segfaulting before)
Because build_gtk and build_gtkagg are no longer config options, there
is a small change in the logic in how the default backend gets set.
Now gtkagg will be set as the default backend if check_for_gtk returns
True. We may want to change this, since tkagg is a little friendlier
across shells.
JDH
diff.out (20.5 KB)
···
On Tue, Nov 9, 2010 at 3:48 PM, Eric Firing <efiring@...229...> wrote:
On 11/09/2010 11:03 AM, John Hunter wrote:
Based on a very superficial look, I suspect we could eliminate
pixbuf_get_pixels_array by using the function
Overview — PyGObject.
John,
I gave your latest patch a try and I noticed something odd while doing the animation examples. I don’t know if this is a result of my special desktop configuration. I am using Ubuntu Netbook Remix, which uses Maxiumus to automatically maximize all windows that open (including matplotlib figure windows).
When running some of the animations (not all of them), the chart is distorted and remains so after un-maximizing. I have included some screenshots to show what I mean. This isn’t the first time that Maximus has caused issues for me, because it does break many developers’ assumptions about their program windows. I am not sure if the problem is limited to just Maximus, or if anybody else can reproduce my manually maximizing their windows.
Ben Root
···
On Tue, Nov 9, 2010 at 4:23 PM, John Hunter <jdh2358@…149…> wrote:
On Tue, Nov 9, 2010 at 3:48 PM, Eric Firing <efiring@…229…> wrote:
On 11/09/2010 11:03 AM, John Hunter wrote:
Based on a very superficial look, I suspect we could eliminate
pixbuf_get_pixels_array by using the function
http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk–pixbuf-new-from-data.
Nice find – this does the trick. I was able to plug it into gdk
draw_image and draw_mathtext fairly painlessly. I’ve now removed all
the gtk compile time dependencies in the attached patch against svn
HEAD. Because this is a major change, I’m going to hold off
committing it to give you all a change to review and test, and I’ll
test some more on a different platform when I get home. But on
solaris python2.4, I have animations with blitting in gtkagg, images
and mathtext in GTK/GDK, so this is looking pretty good so far (all of
this was segfaulting before)
Because build_gtk and build_gtkagg are no longer config options, there
is a small change in the logic in how the default backend gets set.
Now gtkagg will be set as the default backend if check_for_gtk returns
True. We may want to change this, since tkagg is a little friendlier
across shells.
JDH
Thanks for testing Ben -- I'm seeing some of these artifacts too, eg
on examples/animation/subplots.py. I may be transposing a row/col
argument somewhere, which is easy to do. Also, I'll have to dig into
the animations.py code a little more to make sure it is doing the
copy_from_bbox background after each draw event so that everything is
properly sized. Since these examples worked fine before my changes,
though, it is pretty clear where the culprit is 
JDH
···
On Tue, Nov 9, 2010 at 7:57 PM, Benjamin Root <ben.root@...553...> wrote:
I gave your latest patch a try and I noticed something odd while doing the
animation examples. I don't know if this is a result of my special desktop
configuration. I am using Ubuntu Netbook Remix, which uses Maxiumus to
automatically maximize all windows that open (including matplotlib figure
windows).
When running some of the animations (not all of them), the chart is
distorted and remains so after un-maximizing. I have included some
screenshots to show what I mean. This isn't the first time that Maximus has
caused issues for me, because it does break many developers' assumptions
about their program windows. I am not sure if the problem is limited to
just Maximus, or if anybody else can reproduce my manually maximizing their
windows.
Just because animations.py worked before doesn't mean it wasn't
broken. Sequencing of copy_from_bbox with draw_events was one of
the pain points for me and something I want to make easier to get
right from a general Figure() standpoint, which would also address
problems with the macosx backend. (Could be a few months before I can
get back to that level of developing though.) So I wouldn't be
surprised if you revealed I'm doing something wrong in this case.
Ryan
···
On Tue, Nov 9, 2010 at 9:20 PM, John Hunter <jdh2358@...149...> wrote:
Thanks for testing Ben -- I'm seeing some of these artifacts too, eg
on examples/animation/subplots.py. I may be transposing a row/col
argument somewhere, which is easy to do. Also, I'll have to dig into
the animations.py code a little more to make sure it is doing the
copy_from_bbox background after each draw event so that everything is
properly sized. Since these examples worked fine before my changes,
though, it is pretty clear where the culprit is
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
