Autonomous display of image/plot/figure

Community matplotlib-users
1

James K. Gruetzner wrote:

I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8 from
the yum repository. Backend is set to GTKAgg in my matplotlibrc file.

(On this list top-posting is frowned upon -- it makes the conversation
difficult to follow.)

I understand. Sorry. Each list is different: I'm new here, and will try remember.

No problem. Also, don't forget reply-to-all, so that the whole of the list can chime in here. :slight_smile:

Your analysis is correct, the call to show() activates the GUI mainloop
and does not return until the window is closed. Within ipython there is
some magic that occurs that runs the mainloop in a separate thread.
What do you need to do after the call to show()?

In my current situation, I need to extract and display data (images) independently from several different files as part of debugging a larger application. (I'm really not reading a file into the original array, but running some shell commands using os.popen2(...) to eventually populate the array: that part works.) The upshot is that in the course of a few hours, I may have to display (and kill) a large number of images.

The current "hang" means that I have an effective memory leak, and I'd have to keep track of Process IDs and manually kill them every so often. Were the pylab.show() command to return after closing the window (clicking on the X), then a backgrounded or daemon process should terminate. But it doesn't. This seems to be the same problem causing Dragan S.'s problem.

I'm not sure if this is a bug or a feature, but would assuredly like to find a way to kill the leak.

I'm not sure about the lack of returning after the call show(), though it does sound like a bug. What I *do* know is that multiple calls to show() is frowned upon (if not just completely unsupported). What you probably want to look at is the dynamic_image_gtkagg.py example (in the examples/ directory). Since you're already using GtkAgg, it should be *really* easy to adapt the example to fit your needs. I've personally adapted it to do a live data display of a simulation run. If you *need* it to wait for user interaction before continuing, there might be a little bit more work, but I don't think it'd be much. You could probably instead look at some of the Matplotlib UI widgets, like in the buttons.py example.

Ryan

路路路

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

2

James K. Gruetzner wrote:
>>> I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8 from
>>> the yum repository. Backend is set to GTKAgg in my matplotlibrc file.
>>
>> (On this list top-posting is frowned upon -- it makes the conversation
>> difficult to follow.)
>
> I understand. Sorry. Each list is different: I'm new here, and will
> try remember.

No problem. Also, don't forget reply-to-all, so that the whole of the
list can chime in here. :slight_smile:

Arrrgh!!!! Almost all my other lists have that as default, so I'm out of the
habit of checking.

>> Your analysis is correct, the call to show() activates the GUI mainloop
>> and does not return until the window is closed. Within ipython there is
>> some magic that occurs that runs the mainloop in a separate thread.
>> What do you need to do after the call to show()?

> In my current situation, I need to extract and display data (images)
> independently from several different files as part of debugging a larger
> application. (I'm really not reading a file into the original array, but
> running some shell commands using os.popen2(...) to eventually populate
> the array: that part works.) The upshot is that in the course of a
> few hours, I may have to display (and kill) a large number of images.

> The current "hang" means that I have an effective memory leak, and I'd
> have to keep track of Process IDs and manually kill them every so often.
> Were the pylab.show() command to return after closing the window
> (clicking on the X), then a backgrounded or daemon process should
> terminate. But it doesn't. This seems to be the same problem causing
> Dragan S.'s problem.

> I'm not sure if this is a bug or a feature, but would assuredly like to
> find a way to kill the leak.

I'm not sure about the lack of returning after the call show(), though
it does sound like a bug. What I *do* know is that multiple calls to
show() is frowned upon (if not just completely unsupported). What you
probably want to look at is the dynamic_image_gtkagg.py example (in the
examples/ directory). Since you're already using GtkAgg, it should be
*really* easy to adapt the example to fit your needs. I've personally
adapted it to do a live data display of a simulation run.

I don't really need any live interaction or a live data display; I just want
the thang to stop running (i.e., the process to terminate) when the figure
window is closed.

Unfortunately, the
  dynamic_image_gtkagg.py
example has the same problem. It's final line is "show()". When run as a
background process, everything displays well --- but when the window is
closed (click on X), the process fails to terminate. So . . . the root
cause is that show() does not return when the shown image is closed.

If you *need* it to wait for user interaction before continuing, there might
be a little bit more work, but I don't think it'd be much. You could
probably instead look at some of the Matplotlib UI widgets, like in the
buttons.py example.

I really don't need user interaction per se, I may have to go that route an
establish some sort of "close window and exit" event. Hmmm: another
learning opportunity . . . . :slight_smile:

The show() function is defined in
    .../matplotlib/backends/backend_gtk.py
and looks to be calling gtk.main(), which, according to
   .../gtk-2.0/gtk/__init__.py
appears to be deprecated in favor of mainloop().

And that's as far as I can go in this: I'm not graphics whiz, and, in fact,
having reached somewhat beyond my skill level, can't even figure out how to
trace the mainloop call back further.

I would think that the gtk mainloop would terminate when the window closes
(which termination should propagate back up the stack), but apparently that
doesn't happen.

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Thanks again for your help thus far.

   James

路路路

On Thursday 10 July 2008 18:50:12 you wrote:

3

James K. Gruetzner wrote:

I don't really need any live interaction or a live data display; I just want the thang to stop running (i.e., the process to terminate) when the figure window is closed.

Unfortunately, the dynamic_image_gtkagg.py
example has the same problem. It's final line is "show()". When run as a background process, everything displays well --- but when the window is closed (click on X), the process fails to terminate. So . . . the root cause is that show() does not return when the shown image is closed.

If you *need* it to wait for user interaction before continuing, there might
be a little bit more work, but I don't think it'd be much. You could
probably instead look at some of the Matplotlib UI widgets, like in the
buttons.py example.

I really don't need user interaction per se, I may have to go that route an establish some sort of "close window and exit" event. Hmmm: another learning opportunity . . . . :slight_smile:

The show() function is defined in
    .../matplotlib/backends/backend_gtk.py
and looks to be calling gtk.main(), which, according to .../gtk-2.0/gtk/__init__.py
appears to be deprecated in favor of mainloop().

And that's as far as I can go in this: I'm not graphics whiz, and, in fact, having reached somewhat beyond my skill level, can't even figure out how to trace the mainloop call back further.

I would think that the gtk mainloop would terminate when the window closes (which termination should propagate back up the stack), but apparently that doesn't happen.

I'm not sure I'm following you at the moment. Are you calling show() once and closing the figure doesn't cause it to return? or are you trying to call show() multiple times from a single script and subsequent calls to show() fail to return?

Ryan

路路路

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

4

To make sure I capture all the events that can close the window, I
usually connect to the delete-event and the destroy-event. Eg::

  win.connect("delete_event", gtk.mainquit)
  win.connect("destroy_event", gtk.mainquit)

where win is your gtk window.

JDH

路路路

On Fri, Jul 11, 2008 at 11:55 AM, James K. Gruetzner <jkgruet@...176...> wrote:

And that's as far as I can go in this: I'm not graphics whiz, and, in fact,
having reached somewhat beyond my skill level, can't even figure out how to
trace the mainloop call back further.