Hi-
I've got two Intel OSX machines running matplotlib.
I recently upgraded one of them to the latest MPL svn. On one machine,
I had some pytz-related problems which I resolved, and I was able to use
it more or less fine. However, when the very first time I started it,
there was a huge pause
Andrew Jaffe wrote:
> Hi-
>
> I've got two Intel OSX machines running matplotlib.
>
> I recently upgraded one of them to the latest MPL svn. On one machine,
> I had some pytz-related problems which I resolved, and I was able to use
> it more or less fine. However, when the very first time I s
I think that's something I recently introduced, and should probably be simple
to fix. I'll have a look when I get into the office this morning.
Cheers,
Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping th
There is a (probable) fix for this in SVN r4179. I can't get to a Mac
to test right now -- can you please confirm that fixes your problem?
You may need to remove ~/.matplotlibrc/fontManager.cache (just once) in
case the earlier bug has messed up the cache.
Andrew Jaffe wrote:
> Andrew Jaffe wr
OK, the fix in the latest SVN does seem to work.
Andrew
On 9 Nov 2007, at 13:24, Michael Droettboom wrote:
> There is a (probable) fix for this in SVN r4179. I can't get to a
> Mac to test right now -- can you please confirm that fixes your
> problem? You may need to remove ~/.matplotlibrc/
Michael Droettboom wrote:
> Christopher Barker wrote:
>> Michael Droettboom wrote:
>>> Wx supports polycurves in its new wxGraphicsContext API (but not the
>>> wxDC API that mpl uses now). This means a fairly complete rewrite of
>>> the wx backend,
>> not necessarily. You can create a GraphicsCo
On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I've committed my changes on the transforms branch so you can play with
> it -- I'm holding off on changing the trunk due to the pending release.
> But if everyone agrees on the way to expose this, it would be nice to
> merge
[To summarize an off-list conversation -- Eric and I had been discussing
ways to speed up pcolor plots. After some improvements, quadmeshes are
still about a factor of 2 slower on the branch than on the trunk. His
use case often involves the simpler problem of rectilinear meshes, which
can be
John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it
John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it
Eric Firing wrote:
> Mike,
>
> Thank you for once again blasting out such an array of improvements.
> Regarding implementation and API details, such as what should go in
> imshow versus pcolor versus something with another name, I would like to
> review the situation (and your branch) and come u
On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote:
> Eric Firing wrote:
> > Mike,
> >
> > Thank you for once again blasting out such an array of improvements.
> > Regarding implementation and API details, such as what should go in
> > imshow versus pcolor versus something with another
Darren Dale wrote:
> On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote:
>> Eric Firing wrote:
>>> Mike,
>>>
>>> Thank you for once again blasting out such an array of improvements.
>>> Regarding implementation and API details, such as what should go in
>>> imshow versus pcolor versus
Mike,
Thank you for once again blasting out such an array of improvements.
Regarding implementation and API details, such as what should go in
imshow versus pcolor versus something with another name, I would like to
review the situation (and your branch) and come up with a
recommendation, but I
Michael,
Have you looked at the speed of zooming in and out with pcolormesh?
On Nov 9, 2007 3:33 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Darren Dale wrote:
> > On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote:
> >> Eric Firing wrote:
> >>> Mike,
> >>>
> >>> Thank you fo
Sorry, I didn't explain the benchmark (which was in an off-list e-mail
to Eric.) The "fps" value in these benchmarks is the frames-per-second
you get when updating the range of the axes (approximately what to
expect from an interactive pan/zoom operation). The "init" time is the
time it takes
On Fri, Nov 09, 2007 at 01:39:10PM -0600, John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
> > I've committed my changes on the transforms branch so you can play with
> > it -- I'm holding off on changing the trunk due to the pending release.
> > But if
Hello,
I was using the "configure subplots" dialog a lot recently to precisely
resize my plots, and I noticed that often when I changed a slider only
slightly (say by 1 pixel), the numeric value displayed next to the
slider wouldn't change, because its precision was too low. So, I
modified th
18 matches
Mail list logo
