Hi,
In an application that updates a plot with
new experimental data, say, every second and the experiment
can last hours, I have tried two approaches:
1) clear axes and plot new experimental data - this is
slow and takes too much cpu resources.
2) remove lines and plot new experimental data -
On 05/28/2010 09:18 AM, Pearu Peterson wrote:
, say, every second and the experiment
can last hours, I have tried two approaches:
1) clear axes and plot new experimental data - this is
slow and takes too much cpu resources.
2) remove lines and plot new experimental data - this is
fast enough
On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson pe...@cens.ioc.ee wrote:
Hi,
In an application that updates a plot with
new experimental data, say, every second and the experiment
can last hours, I have tried two approaches:
1) clear axes and plot new experimental data - this is
slow and
I'm on to something -- some callbacks are being created that are never
disconnected.
In Line2D.set_axes:
self._xcid = ax.xaxis.callbacks.connect('units', self.recache_always)
gets called twice. This is problematic because the id of the first
connection is simply lost. Also, there doesn't
On Fri, May 28, 2010 at 10:52 AM, Jason Grout
jason-s...@creativetrax.com wrote:
I just noticed here:
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim
that the keywords that are documented for set_xlim are actually the
keywords for set_ylim. Surely this is
There is a fix in r8341. It passes the regression tests, and all of the
event handling examples I tried seem to still work.
It seems that many places in matplotlib were never disconnecting
callbacks, and these callbacks keep references to the destination
objects alive.
Unfortunately, it's
On Fri, May 28, 2010 5:12 pm, John Hunter wrote:
Hey Pearu -- thanks for the report. We'll try and track down and fix
this leak. In the interim, would an acceptable work around for you be
to *reuse* an existing line by calling set_data on it. That way you
wouldn't have to do the add/remove
On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson pe...@cens.ioc.ee wrote:
Regarding reusing existing line --- I have understood that this
will work only if the length of the line data does not change.
This is not correct -- you can change the line length with calls to set_data
In my case the
On 05/28/2010 08:04 AM, Pearu Peterson wrote:
On Fri, May 28, 2010 5:12 pm, John Hunter wrote:
Hey Pearu -- thanks for the report. We'll try and track down and fix
this leak. In the interim, would an acceptable work around for you be
to *reuse* an existing line by calling set_data on it.
On Fri, May 28, 2010 9:15 pm, John Hunter wrote:
On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson pe...@cens.ioc.ee wrote:
Regarding reusing existing line --- I have understood that this
will work only if the length of the line data does not change.
This is not correct -- you can change the
On Fri, May 28, 2010 at 1:37 PM, Pearu Peterson pe...@cens.ioc.ee wrote:
While the new data is plotted correctly, the plot shows fixed axes
from the first plot call. What I am doing wrong?
ax.relim() causes the data limits to be updated based on the current
objects it contains,
Thanks, John!
Adding ax.autoscale_view after ax.relim makes the script work correctly.
Best regards,
Pearu
--
___
Matplotlib-devel mailing list
Hi,
Ben Root gave me a bug report that pcolormesh (and hence QuadMesh)
were not respecting zorder. This turns out to be due to the fact that
kwargs are not being forwarded on as appropriate. This is easy enough
to fix and make work, but I wanted to first ask for any insight on the
following
Thanks, John!
Calling ax.autoscale_view after ax.relim makes the script work.
Best regards,
Pearu
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
14 matches
Mail list logo
