matplotlib-devel Mailing List for matplotlib

On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root <ben...@gm...> wrote:
> Hello all,
>
> I have always been a bit troubled with how Axes3D object is a bit of a
> 2nd-class citizen in matplotlib.  In particular, it is very common to create
> a new axes using .add_subplot() or .gca(), but you can't do that with
> Axes3D.  You also can't create subplots of 3d figures, you have to create
> multiple figures with single 3d plots in them.
>
> My examination off the code have not revealed anything that prevents this
> from happening.  Currently, the gca() and add_subplot() functions accept a
> kwarg of 'projection' which allows one to specify the name of a registered
> axes object.  Currently axes.Axes, polar and a few others are registered,
> with axes.Axes being default.
>
> I have found that 3 lines of code in the axes3d module to have it add the
> Axes3D class to the registry.  Using a name of '3d', one can specify the
> projection to gain a Axes3d object.  Note, you will still have to import the
> Axes3D object as usual.  Attached is a patch for axes3d.py and a file that
> could be added to mpl_examples/.  Give it a shot and let me know how it
> works for you!
>
> Enjoy!
> Ben Root

Definitely interested.  Thanks for the re-ping.  Reinier is busy of
late so hasn't been able to get to the 3D stuff.  Damned Germans and
their endless vacations -- actually my wife is German currently on an
endless vacation so shouldn't complain :-)

I am not a 3D user currently and was not even aware of the "one axes"
limitation you describe.  So would this also prevent mixing 2D and 3D
in the same figure (in the trunk before your patch)?  This looks like
a major and unobtrusive improvement.  I tested it and it looks good.
Committed to 8497.

Perhaps you can update doc/mpl_toolkits/mplot3d/tutorial.rst showing
how to use the projection kwarg to mix 2D w/ 3D or place multiple 3D
plots in one figure.

If you'd like svn commit rights, send me your sf id.

> P.S. - Can you just imagine subplots of animated 3d plots? wink... wink...

Damn, better get a new computer.  I am doing my development currently
on a linux install running on a laptop under Sun VirtualBox.  Even
typing an email can be painfully slow.  Multiple animated mpl subplots
would definitely bring this box to it's knees.  Well, technically,
it's already on its knees.

JDH

Just re-pinging to see if there is any interest in this patch.

Ben Root

On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root <ben...@gm...> wrote:

> Hello all,
>
> I have always been a bit troubled with how Axes3D object is a bit of a
> 2nd-class citizen in matplotlib.  In particular, it is very common to create
> a new axes using .add_subplot() or .gca(), but you can't do that with
> Axes3D.  You also can't create subplots of 3d figures, you have to create
> multiple figures with single 3d plots in them.
>
> My examination off the code have not revealed anything that prevents this
> from happening.  Currently, the gca() and add_subplot() functions accept a
> kwarg of 'projection' which allows one to specify the name of a registered
> axes object.  Currently axes.Axes, polar and a few others are registered,
> with axes.Axes being default.
>
> I have found that 3 lines of code in the axes3d module to have it add the
> Axes3D class to the registry.  Using a name of '3d', one can specify the
> projection to gain a Axes3d object.  Note, you will still have to import the
> Axes3D object as usual.  Attached is a patch for axes3d.py and a file that
> could be added to mpl_examples/.  Give it a shot and let me know how it
> works for you!
>
> Enjoy!
> Ben Root
>
> P.S. - Can you just imagine subplots of animated 3d plots? wink... wink...
>

Although there are many active issues that are undergoing constant
work, none of these seem release critical and we can continue to
improve them on the branch and trunk as need be.  Eric, who has been
doing the lion's share of the work managing, fixing and closing bugs,
feels like we are ready to go and so do I.  So Michael, if you are
available, will you branch the trunk into a 1.0 maintenance branch,
and once the branch is made I will do a final round of testing, cut
the tarball, and ask Christoph and Russell to build the binaries.

If experience is any guide, after a major *.0 release we will need to
cut a bugfix release in the upcoming week or two anyhow, so hopefully
we can get as many active issues settled and released by then.

If you're not available Michael, let me know or I will infer by your
silence and try and make the branch myself from your instructions in
the developers guide.

Thanks,
JDH

On Mon, Jul 5, 2010 at 3:38 PM, Eric Firing <ef...@ha...> wrote:

> On 07/05/2010 10:22 AM, Benjamin Root wrote:
> > After some more digging, I think I finally found the source of my
> > issues.  I have noticed that there are inconsistencies between the keys
> > and sections listed in the default matplotlib.conf file and in the class
> > MPLConfig().  While in most cases, these inconsistencies are innocuous
> > and do not cause errors, I think there have been a few inadvertent
> mistakes.
>
> Ben,
>
> With Darren's permission I went ahead and deleted matplotlib.config from
> svn (r8495), so it will not appear in the next release unless someone
> resurrects it.  It can always be pulled out of the svn history and
> updated, if that turns out to be the thing to do.  For now, though, I
> think that it is better to simplify the mpl tree when possible.  We have
> enough work to do to maintain and improve the parts of mpl that are
> being used.
>
> Eric
>
>
Eric,

No problem, I just noticed that the config directory was removed.  And I
just discovered that when svn deletes a directory full of .py and pyc files,
the .pyc files get left behind and are still accessed by programs like pydoc
that walks the directories searching for packages to load.

Anyway, I am more than happy to help prune down the trunk.  Extra stuff that
isn't being used just add noise and confusion.  Especially to a depth-first
debugger like myself...

Ben Root

 >
> > So, I modified one of the programs to produce a list of all the
> > inconstancies that exist, and I will let you guys figure out what needs
> > to be fixed, or what is intentional.
> >
> > For example, the first item in thee file states that the MPLConfig class
> > do not have the keys "numerix" and "maskedarray", but the default
> > configuration file does.  In addition, the MPLConfig class has the key
> > datapath, but that is not given in the default conf file.  (I do
> > recognize that this should probably be expected in this case, I am
> > merely explaining how to interpret the attached file).
> >
> > The next paragraph states that MPLConfig class defines a section "path",
> > but it is not found in the default configuration file.
> >
> > The other lines that I find interesting:
> >     15 ('preview' is given in the conf file, but not in the class)
> >     31-32 ('embed_chars' is in the default file, but the config class
> > has 'embed_char_paths')
> >     35-36 (many keys between the class and the file are similar, but not
> > the same)
> >
> > The other paragraphs might be interesting, but I hardly know enough to
> > make such determinations.
> >
> > Ben Root
> >
> >
> > On Sun, Jul 4, 2010 at 9:47 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> >
> >
> >     On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale <dsd...@gm...
> >     <mailto:dsd...@gm...>> wrote:
> >
> >         On Sun, Jul 4, 2010 at 9:24 PM, John Hunter <jd...@gm...
> >         <mailto:jd...@gm...>> wrote:
> >          > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root
> >         <ben...@ou... <mailto:ben...@ou...>> wrote:
> >          >> Hello,
> >          >>
> >          >> I came across a typo in mplconfig.py that results in an
> >         error when
> >          >> processing the matplotlib configurations.  Attached is a
> patch.
> >          >
> >          > I can apply this patch because it is a simple fix, but the
> larger
> >          > question is whether we want to distribute/support the traited
> >         config
> >          > at all.  It seems like this development branch is mostly
> >         abandoned.
> >          > Any comments Darren, or others?
> >          >
> >          > But in any case as long as we *do* currently have it it is
> >         good to fix
> >          > these bugs, so thanks for the patch.
> >
> >         The traited config stuff was never supported, and has to be
> >         turned on
> >         by setting a global in the source code. So I don't think it makes
> >         sense to distribute it. I'm too busy these days to try to
> >         support this
> >         feature and make it the default, plus there were issues with
> >         additional overhead due to pkg_resources, traits, and configobj.
> I
> >         wouldn't be offended if the code was removed from the trunk.
> >         (sniffs)
> >
> >         Darren
> >
> >
> >     Do you guys still want a bug report for the tconfig issue, just in
> >     case it might be related to Traits in general (I have no clue where
> >     the issue is happening)?
> >
> >     Ben
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 07/05/2010 10:22 AM, Benjamin Root wrote:
> After some more digging, I think I finally found the source of my
> issues.  I have noticed that there are inconsistencies between the keys
> and sections listed in the default matplotlib.conf file and in the class
> MPLConfig().  While in most cases, these inconsistencies are innocuous
> and do not cause errors, I think there have been a few inadvertent mistakes.

Ben,

With Darren's permission I went ahead and deleted matplotlib.config from 
svn (r8495), so it will not appear in the next release unless someone 
resurrects it.  It can always be pulled out of the svn history and 
updated, if that turns out to be the thing to do.  For now, though, I 
think that it is better to simplify the mpl tree when possible.  We have 
enough work to do to maintain and improve the parts of mpl that are 
being used.

Eric

>
> So, I modified one of the programs to produce a list of all the
> inconstancies that exist, and I will let you guys figure out what needs
> to be fixed, or what is intentional.
>
> For example, the first item in thee file states that the MPLConfig class
> do not have the keys "numerix" and "maskedarray", but the default
> configuration file does.  In addition, the MPLConfig class has the key
> datapath, but that is not given in the default conf file.  (I do
> recognize that this should probably be expected in this case, I am
> merely explaining how to interpret the attached file).
>
> The next paragraph states that MPLConfig class defines a section "path",
> but it is not found in the default configuration file.
>
> The other lines that I find interesting:
>     15 ('preview' is given in the conf file, but not in the class)
>     31-32 ('embed_chars' is in the default file, but the config class
> has 'embed_char_paths')
>     35-36 (many keys between the class and the file are similar, but not
> the same)
>
> The other paragraphs might be interesting, but I hardly know enough to
> make such determinations.
>
> Ben Root
>
>
> On Sun, Jul 4, 2010 at 9:47 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>
>
>     On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale <dsd...@gm...
>     <mailto:dsd...@gm...>> wrote:
>
>         On Sun, Jul 4, 2010 at 9:24 PM, John Hunter <jd...@gm...
>         <mailto:jd...@gm...>> wrote:
>          > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root
>         <ben...@ou... <mailto:ben...@ou...>> wrote:
>          >> Hello,
>          >>
>          >> I came across a typo in mplconfig.py that results in an
>         error when
>          >> processing the matplotlib configurations.  Attached is a patch.
>          >
>          > I can apply this patch because it is a simple fix, but the larger
>          > question is whether we want to distribute/support the traited
>         config
>          > at all.  It seems like this development branch is mostly
>         abandoned.
>          > Any comments Darren, or others?
>          >
>          > But in any case as long as we *do* currently have it it is
>         good to fix
>          > these bugs, so thanks for the patch.
>
>         The traited config stuff was never supported, and has to be
>         turned on
>         by setting a global in the source code. So I don't think it makes
>         sense to distribute it. I'm too busy these days to try to
>         support this
>         feature and make it the default, plus there were issues with
>         additional overhead due to pkg_resources, traits, and configobj. I
>         wouldn't be offended if the code was removed from the trunk.
>         (sniffs)
>
>         Darren
>
>
>     Do you guys still want a bug report for the tconfig issue, just in
>     case it might be related to Traits in general (I have no clue where
>     the issue is happening)?
>
>     Ben
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

./matplotlib/lib/matplotlib/mpl-data/matplotlib.conf
Inconsistencies found for section: MPLConfig
These keys are missing from the config class: ['maskedarray', 'numerix']
And the config class has these: ['datapath']

Inconsistencies found within section: MPLConfig
These subsections are missing from the config class : []
And the config class has these : ['path']

Inconsistencies found for section: text
These keys are missing from the config class: []
And the config class has these: ['hinting']

Inconsistencies found for section: latex
These keys are missing from the config class: ['preview']
And the config class has these: []

Inconsistencies found for section: mathtext
These keys are missing from the config class: []
And the config class has these: ['default']

Inconsistencies found for section: path
These keys are missing from the config class: []
And the config class has these: ['snap', 'simplify', 'simplify_threshold']

Inconsistencies found for section: backend
These keys are missing from the config class: []
And the config class has these: ['fallback']

Inconsistencies found for section: svg
These keys are missing from the config class: ['embed_chars']
And the config class has these: ['embed_char_paths']

Inconsistencies found for section: legend
These keys are missing from the config class: ['handlelength', 'labelspacing', 'columnspacing', 'handletextpad', 'borderaxespad', 'borderpad']
And the config class has these: ['handletextsep', 'axespad', 'pad', 'labelsep', 'handlelen']

http://www.mail-archive.com/mat...@li.../msg06691.html

Looking back through mail, I noticed the above thread that was still 
hanging with respect to 1.0.

A few minutes ago, in 8494, I went ahead and committed a change that 
makes show block in tkagg and fltkagg, just as it does in all the other 
interactive backends.  As usual, other developers are *welcome* *to* 
*revert* this change; but I think it is an important one to get into 1.0 
if possible, since it helps smooth out an inconsistency that keeps 
surprising users.

Again, I hope someone can test 8494 right now.  It would be especially 
useful if someone with an older OS version could test it.  I run ubuntu 
10.04, so there is always the danger that something that works fine for 
me might not work for someone with an old RHEL or Windows XP or OSX 
10.4.  The change affects *only*  show() on tkagg and fltkagg.  I don't 
expect it will magically make all backends work exactly the same in all 
possible environments (ipython -pylab, idle, etc.), but as far as I can 
tell it is a step in the right direction; I don't expect it to make 
anything substantially worse.

In retrospect, I think I was too cautious; I should have simply made the 
change in svn 3 weeks ago.  The only way to get much testing of 
something like this is to put it in by default--not as an option 
requiring deliberate testing--and see if anyone trips over it.

Eric

On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas <ian...@go...> wrote:

> Yes, it does indeed take a long time for large grids. The bottleneck is line
> 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a
> separate Line2D object for each edge in the triangulation, and there can be
> a lot of edges.  There is an obvious improvement of replacing this with a
> single LineCollection object, but it would require some manipulation of the
> line styles, colours, etc that the plot command does and I don't yet
> understand it sufficiently.

This could be made much faster using a compound Path for the edges and
a single call to "plot" for the markers on the flattened array of
vertices.  You would retain the generality of all the mpl markers in
this case, since you would be using "plot" for the verticies, but
might lose some of the generality of the line styles since we don't
have a class "LinePath" like we do in matplotlib.patches.PathPatch (eg
see http://matplotlib.sourceforge.net/examples/api/compound_path.html).
 It would be nice to see an analogue or PathPatch
matplotlib.lines.LinePath that exposes the relevant bits of the Line2D
interface (set_linestyle) etc, but you can get most of this by setting
facecolor='None' in the PathPatch.  In practice, you almost always
want a solid line for the edges I suspect.

In a nutshell, you could still support the plot format string but
manually pass it to Axes._process_plot_format.  Use the returned
results to set the properties on a single call to plot for the
flattened array of vertex markers, and a single compound PathPatch
with no facecolor for the edges (or you could support the facecolor if
you want).  Since PathPatch already supports linestyle, edgecolor and
linewidth, it should work.  And Paths support masks, so you should be
able to integrate the masking but I am not sure about this part since
I haven't delved deeply enough into the tri code to see how masking is
applied.

JDH

On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo <ac...@ne...> wrote:
> I'm really sorry for my comment, it was not my intention to offend anyone.
> You are absolutely right about that, therefore I would like to apologize to
> all developers, in particular to you, for my comment regarding the matlab
> comparison.
> The only thing I can promise is that won't happen again... sorry!!!

Speaking for myself , I did not find your comment offensive.  It is
true we are an all-volunteer organization and do not strive to
duplicate matlab, but I took your comment to mean that the plotting
could be done efficiently as evidenced by matlab, so there was no
algorithmic reason it should be as slow as it is.  Those kinds of
comments, phrased gently and constructively, are generally welcome.
The tri functionality is quite new, not yet in any released versions
of mpl but that is soon to change, and often users have to pound on
new functionality for a while to shake out inefficiencies

As Ian noted, anywhere we use a long list of Line2D objects (or calls
to plot in a loop) is prone to be very slow, and we should be able to
get substantial performance improvements using a collection.

Cheers,
JDH

Hello Ian,

I'm really sorry for my comment, it was not my intention to offend anyone.
You are absolutely right about that, therefore I would like to apologize 
to all developers, in particular to you, for my comment regarding the 
matlab comparison.
The only thing I can promise is that won't happen again... sorry!!!

You said that the obsolete triplot has the same code lines. I don't know 
what has changed between the two versions, but the fact is that I made 
many plots when I was using mpl_tri (yes, it take a while, but not so 
long as with the new version).

Best regards,
Alberto

On 05-07-2010 9:17, Ian Thomas wrote:
> Hello again Alberto,
>
> On 4 July Alberto Azevedo wrote:
>
>     When I use the triplot function with 100-1000 points it works
>     well. The
>     problem is that in my work I often use grids with 30000-100000
>     points. With those grids triplot takes a long time to compute (I never
>     wait for the results, it takes really a long time).
>
>
> Yes, it does indeed take a long time for large grids. The bottleneck 
> is line 51 in lib/matplotlib/tri/triplot - I use the plot command 
> which creates a separate Line2D object for each edge in the 
> triangulation, and there can be a lot of edges.  There is an obvious 
> improvement of replacing this with a single LineCollection object, but 
> it would require some manipulation of the line styles, colours, etc 
> that the plot command does and I don't yet understand it sufficiently.
>
>     The matlab triplot function takes just a few seconds, with the same
>     grids).
>
>
> It's bad etiquette to indicate that matlab is faster when addressing 
> people who give up their free time to improve matplotlib, and possibly 
> counter-productive.
>
>     And when I was using mpl_tri package, I never had this problem
>     (the triplot function was faster!!!)
>
>
> Not true, the final line in the now obsolete mpl_tri.triplot was 
> exactly the same plot() command.
>
> I'll take a look at improving the performance, but it won't for a few 
> days.
>
> Ian





=======
E-mail verificado pelo Spyware Doctor – Não foram encontrados vírus ou spyware.
(Email Guard: 7.0.0.18, Base de dados de vírus/spyware: 6.15350)
http://www.pctools.com/?cclick=EmailFooterClean_51
=======

Hello again Alberto,

On 4 July Alberto Azevedo wrote:

> When I use the triplot function with 100-1000 points it works well. The
> problem is that in my work I often use grids with 30000-100000
> points. With those grids triplot takes a long time to compute (I never
> wait for the results, it takes really a long time).
>

Yes, it does indeed take a long time for large grids. The bottleneck is line
51 in lib/matplotlib/tri/triplot - I use the plot command which creates a
separate Line2D object for each edge in the triangulation, and there can be
a lot of edges.  There is an obvious improvement of replacing this with a
single LineCollection object, but it would require some manipulation of the
line styles, colours, etc that the plot command does and I don't yet
understand it sufficiently.

The matlab triplot function takes just a few seconds, with the same
> grids).


It's bad etiquette to indicate that matlab is faster when addressing people
who give up their free time to improve matplotlib, and possibly
counter-productive.

And when I was using mpl_tri package, I never had this problem
> (the triplot function was faster!!!)
>

Not true, the final line in the now obsolete mpl_tri.triplot was exactly the
same plot() command.

I'll take a look at improving the performance, but it won't for a few days.

Ian

On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale <dsd...@gm...> wrote:

> On Sun, Jul 4, 2010 at 9:24 PM, John Hunter <jd...@gm...> wrote:
> > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
> >> Hello,
> >>
> >> I came across a typo in mplconfig.py that results in an error when
> >> processing the matplotlib configurations.  Attached is a patch.
> >
> > I can apply this patch because it is a simple fix, but the larger
> > question is whether we want to distribute/support the traited config
> > at all.  It seems like this development branch is mostly abandoned.
> > Any comments Darren, or others?
> >
> > But in any case as long as we *do* currently have it it is good to fix
> > these bugs, so thanks for the patch.
>
> The traited config stuff was never supported, and has to be turned on
> by setting a global in the source code. So I don't think it makes
> sense to distribute it. I'm too busy these days to try to support this
> feature and make it the default, plus there were issues with
> additional overhead due to pkg_resources, traits, and configobj. I
> wouldn't be offended if the code was removed from the trunk. (sniffs)
>
> Darren
>

Do you guys still want a bug report for the tconfig issue, just in case it
might be related to Traits in general (I have no clue where the issue is
happening)?

Ben

On Sun, Jul 4, 2010 at 8:24 PM, John Hunter <jd...@gm...> wrote:

> On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
> > Hello,
> >
> > I came across a typo in mplconfig.py that results in an error when
> > processing the matplotlib configurations.  Attached is a patch.
>
> I can apply this patch because it is a simple fix, but the larger
> question is whether we want to distribute/support the traited config
> at all.  It seems like this development branch is mostly abandoned.
> Any comments Darren, or others?
>
> But in any case as long as we *do* currently have it it is good to fix
> these bugs, so thanks for the patch.
>
> JDH
>

Thanks for applying that patch.  I should also note that I am still in the
process of tracking down another bug that seems to be related to tconfig.
One can trigger it using the pydoc utility on a local build and install of
matplotlib from svn.  An exception gets raised when searching for
"mpl_toolkits.mplot3d.axes3d" from the pydoc graphical gui, which seems to
do a brute-force examination of the documentation.  So it might be
triggering unmaintained code.

Ben Root

On Sun, Jul 4, 2010 at 9:24 PM, John Hunter <jd...@gm...> wrote:
> On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
>> Hello,
>>
>> I came across a typo in mplconfig.py that results in an error when
>> processing the matplotlib configurations.  Attached is a patch.
>
> I can apply this patch because it is a simple fix, but the larger
> question is whether we want to distribute/support the traited config
> at all.  It seems like this development branch is mostly abandoned.
> Any comments Darren, or others?
>
> But in any case as long as we *do* currently have it it is good to fix
> these bugs, so thanks for the patch.

The traited config stuff was never supported, and has to be turned on
by setting a global in the source code. So I don't think it makes
sense to distribute it. I'm too busy these days to try to support this
feature and make it the default, plus there were issues with
additional overhead due to pkg_resources, traits, and configobj. I
wouldn't be offended if the code was removed from the trunk. (sniffs)

Darren

On Sat, Jul 3, 2010 at 11:53 AM, Ryan May <rm...@gm...> wrote:
> On Sat, Jul 3, 2010 at 1:11 AM, Ryan May <rm...@gm...> wrote:
>> Alright, before I go to bed, I found the following line in
>> src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the
>> difference:
>>
>> set_clipbox(gc.cliprect, rendererBase);
>>
>> Commenting out this line fixes my problem. I'm not sure why it's a
>> problem, (maybe a missing restore to previous state somewhere?). I'll
>> look into this tomorrow, but it would probably be a lot easier with
>> someone familiar with the code.
>
> Following up again, it seems like the problem is that draw_marker is
> calling set_clipbox() on the rendererBase instead of theRasterizer,
> which is done at 7 other places in the code (as opposed to only one
> other location for rendererBase).  Since rendererBase is used for
> restore_region, this makes sense as to why it would fix my problem. I
> can confirm making the change fixes my problem and doesn't cause any
> other issues in my (admittedly brief so far) testing.
>
> (If this isn't the proper fix, an alternative is to call
> rendererBase.reset_clipping(true), but I really think this is working
> around the issue).
>
> Can someone more familiar with the agg backend weigh in here? I'm
> pretty comfortable with the fix, but don't want to be responsible for
> breaking pretty much all of matplotlib.

Does marker clipping still work with the proposed change?

The only thing that is special about marker drawing is we use cached
marker rasters to make drawing many of them efficient, but I don't
recall anymore whether this required special clipping treatment.

JDH

On Sun, Jul 4, 2010 at 4:56 PM, Benjamin Root <ben...@ou...> wrote:
> While I don't think this has caused any problems yet, I have noticed a
> discrepancy in how a button-click test was being done versus other checks in
> the same file.  It also makes more sense to check against a compiled list of
> buttons instead of using a hard-coding value.
>
> Attached is a patch
>

Applied to 8493, thanks!
JDH

On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
> Hello,
>
> I came across a typo in mplconfig.py that results in an error when
> processing the matplotlib configurations.  Attached is a patch.

I can apply this patch because it is a simple fix, but the larger
question is whether we want to distribute/support the traited config
at all.  It seems like this development branch is mostly abandoned.
Any comments Darren, or others?

But in any case as long as we *do* currently have it it is good to fix
these bugs, so thanks for the patch.

JDH