matplotlib-devel Mailing List for matplotlib

Hey Randy,
     All the mpl binaries are built against tcl/tk 8.4.  I believe mpl is
not compatible with tcl/tk 8.5 as of the last release.  Someone else might
know if this has changed in svn?

- Charlie

On Sun, Oct 5, 2008 at 11:04 PM, Randy Heiland <he...@in...> wrote:

> Short/naive question:  do the mpl eggs have a dependency on Tk 8.4?
>
> Longer question:  I'm trying to support a plugin (NLOPredict) to a
> popular molecular vis pkg (UCSF Chimera) and, no surprise, the plugin
> uses mpl.  Chimera bundles its own Python, plus all dependencies.
> The latest version switched to Python 2.5 and Tcl/Tk 8.5.  It also
> bundles numpy 1.0.4.  So I tried to install a mpl-maintenance egg
> (Windows first) that used Python 2.5 and pre-numpy 1.1 (I tried mpl
> 0.91.4 and 91.2).  However, when I bring up the Chimera IDLE, I get:
>
>  >>> from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
> traceback...
> File "d:\chimera-1.2540\bin\lib\site-package\matplotlib-0.91.2-py2.5-
> win32.egg\matplotlib\backends\backend_tkagg.py", line 8, in <module>
>    import tkagg    # Paint image to Tk photo blitter extension
>  File "d:\chimera-1.2540\bin\lib\site-package\matplotlib-0.91.2-
> py2.5-win32.egg\matplotlib\backends\tkagg.py", line 1, in <module>
>    import _tkagg
> ImportError: DLL load failed: The specified file could not be found.
>
>
> Ideas?
> thanks, Randy
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Dear developers,

in matplotlib 0.98.3 I discoverd that in scatter individual alpha 
settings (by giving a list of rgba values) are ignered. Here an example 
that show this behaviour: All points show the same alpha value as given 
by the alpha keyword argument. (Omitting it equals to the setting alpha=1).


from pylab import *

x = [1,2,3]
y = [1,2,3]

c = [[1,0,0, 0.0],
     [1,0,0, 0.5],
     [1,0,0, 1.0]]

gca()
cla()
scatter(x,y, c=c, s = 200, alpha = 0.5)
draw()
show()


I had a look at the sources. In axes.py/scatter I simply removed the line

collection.set_alpha(alpha)

The recent svn version also contains this line.
With this change it worked as expected, also e.g. for the case of a 
single color for all points,

scatter(x,y, c = 'r', alpha = 0.5)

Gregor

Short/naive question:  do the mpl eggs have a dependency on Tk 8.4?

Longer question:  I'm trying to support a plugin (NLOPredict) to a  
popular molecular vis pkg (UCSF Chimera) and, no surprise, the plugin  
uses mpl.  Chimera bundles its own Python, plus all dependencies.   
The latest version switched to Python 2.5 and Tcl/Tk 8.5.  It also  
bundles numpy 1.0.4.  So I tried to install a mpl-maintenance egg  
(Windows first) that used Python 2.5 and pre-numpy 1.1 (I tried mpl  
0.91.4 and 91.2).  However, when I bring up the Chimera IDLE, I get:

 >>> from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
traceback...
File "d:\chimera-1.2540\bin\lib\site-package\matplotlib-0.91.2-py2.5- 
win32.egg\matplotlib\backends\backend_tkagg.py", line 8, in <module>
    import tkagg    # Paint image to Tk photo blitter extension
  File "d:\chimera-1.2540\bin\lib\site-package\matplotlib-0.91.2- 
py2.5-win32.egg\matplotlib\backends\tkagg.py", line 1, in <module>
    import _tkagg
ImportError: DLL load failed: The specified file could not be found.


Ideas?
thanks, Randy

I am getting very inconsistent timings when looking into plotting a line 
with a very large number of points.  Axes.add_line() is very slow, and 
the time is taken by Axes._update_line_limits().  But when I simply run 
the latter, on a Line2D of the same dimensions, it can be fast.

import matplotlib
matplotlib.use('template')
import numpy as np
import matplotlib.lines as mlines
import matplotlib.pyplot as plt
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
from time import time
t = time(); ax.add_line(LL); time()-t
###16.621543884277344
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax.add_line(LL); time()-t
###16.579419136047363
## We added two identical lines, each took 16 seconds.

LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.1733548641204834
## But when we made another identical line, updating the limits was
## fast.

# Below are similar experiments:
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.18362092971801758

## with a fresh axes:
plt.clf()
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.22244811058044434

t = time(); ax.add_line(LL); time()-t
###16.724560976028442

What is going on?  I used print statements inside add_line() to verify 
that all the time is in _update_line_limits(), which runs one or two 
orders of magnitude slower when run inside of add_line than when run 
outside--even if I run the preceding parts of add_line first.

Eric