matplotlib-users — Discussion related to using matplotlib

Re: [Matplotlib-users] default error bar color

[Matt N. <new...@ca...>]

> > > What is a
> > > good attribute name?  I think a method like scale_buoyancy would be
> > > useful too so users wouldn't have to know the default values.
> > 
> > zorder or layer
> 
> or height...

This is an excellent idea, but I'd suggest using the term 'depth'.
Then attributes with larger depth would be drawn below those with
smaller depth.

--Matt Newville <newville at cars.uchicago.edu>

Re: [Matplotlib-users] default error bar color

[Gregory L. <gre...@ff...>]

On Mon, 2004-08-30 at 18:13, Chris Barker wrote:
> Gregory Lielens wrote:
> > I think this ordering is an excellent idea! In fact, I also prefer
> > zorder, or maybe height, or simply z: This can be seen as a
> > z-coordinate, whose only effect would be to change ordering for a 2D
> > plot, but could leads to 3D plots in the future :-)
> 
> Except that z-order and a z coordinate really are different, so we 
> shouldn't use z, it will make it harder, not easier to add 3-plots in 
> the future!

Are they? I think not, cause in 3D you can not control the order of
"painting", this is done so that elements which are in the background
are hidden by elements which are more close to the observer...
Having both a layer info and a z info in 3D would not be consistent
imho, painting at the end an element which should normally be hidden by
others seems like a hack for bypassing normal 3D rendering to me...
And if you use no perspective (infinite focal? ), a 3D plot watched from
above (Z=+inf) would be the same as a 2D plot with z=layer...In fact,
the painting from lower z to higher z is the basic 3D rendering
technique as far as I know...hum, except that the convention used in 3D
is z increasing means further away from the observer, so highest z =
first to be painted, which destroy my argument for "Large number printed
last", oups ;-)

Re: [Matplotlib-users] default error bar color

[Chris B. <Chr...@no...>]

Gregory Lielens wrote:
> I think this ordering is an excellent idea! In fact, I also prefer
> zorder, or maybe height, or simply z: This can be seen as a
> z-coordinate, whose only effect would be to change ordering for a 2D
> plot, but could leads to 3D plots in the future :-)

Except that z-order and a z coordinate really are different, so we 
shouldn't use z, it will make it harder, not easier to add 3-plots in 
the future!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Matplotlib-users] Bar charts with dates as X axis?

[Hubert H. <hu...@tc...>]

Hello,

I am trying to construct a plot that is a barchart with the X-axis being
dates.  I have used the plot_dates to generated line plots that look
great, however, other than turning the dates into integers myself I cannot
figure out a way to do a barchart with dates as the Xaxis.

Has anyone done one of these - I am using the wxPython backend, if that
matters.

Thanks!

Hubert Hickman

[Matplotlib-users] graphic scale

[Xavier M. <Me...@mr...>]

Hi,

I am a new user of matplotlib.
I have already plot some data whit it but, I can't find the way to control 
the axis scales ...
I know how to define the min/max number for each axis. Is it possible to 
define the intermediate scale values ??
For example , the x - axis marks are (automatically) choosen :0 , 0.2 , 0.4 
, 0.6 , 0.8 , 1.0
Can I have instead the values 0, 0.5 , 1.0 written on the axis ?

Best regards,
Xavier.

Re: [Matplotlib-users] markerfacecolor, imshow

[John H. <jdh...@ac...>]

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> Hi there I just recently upgraded my copy of matplotlib to
    Jon> 0.61 (from 0.54!)  and have found a couple of my scripts no
    Jon> longer working. It seems that, for plot(), the argument
    Jon> markerfacecolor no longer takes a color triplet, but requires
    Jon> a string ('w', 'k' etc). markerEDGEcolor is still happy to
    Jon> take either form of color descriptor.

When you say, "no longer takes a color triplet" do you mean "causes an
error".  I tried an example and got an exception.  Simple fix: in
matplotlib/lines.py, at the top of the code import is_string_like from
matplotlib.cbook, ie,

from cbook import True, False, iterable, is_string_like

and at the end of the code, replace the _get_rgb_face method with

    def _get_rgb_face(self):
        if (self._markerfacecolor is None or
            (is_string_like(self._markerfacecolor) and
             self._markerfacecolor.lower()=='none') ): rgbFace = None
        else: rgbFace = colorConverter.to_rgb(self._markerfacecolor)
        return rgbFace

Thanks for letting me know,
JDH

Re: [Matplotlib-users] markerfacecolor, imshow

[John H. <jdh...@ac...>]

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> On a different topic, imshow() only seems to display a single
    Jon> image at a time.  e.g. in the following example, when image2
    Jon> is drawn image1 is deleted.
    Jon> #------------------------------------------------- import
    Jon> matplotlib.matlab as mat myImage = mat.imread('image1.png')
    Jon> myImage2 = mat.imread('image2.png') mat.imshow(myImage,
    Jon> extent=[0,1,0,1]) mat.imshow(myImage2, extent=[1,2,1,2])
    Jon> mat.axis([0, 2, 0, 2]) mat.show()
    Jon> #------------------------------------------------- Is that a
    Jon> known issue? Is there a workaround?

    Jon> all the best, Jon

Ahh, interesting case.  I put the following line in the Axes.imshow
code to protect users from senselessly piling up lots of images

        if alpha==1: self._images = []

That is, I cleared the image stack if alpha was 1, reasoning you can't
see behind a fully opaque image; I was afraid someone might plot lots
of images to the same axes with alpha=1 , and never know they were
piling up images and hurting performance.  I had neglected to consider
that you might be using multiple images with different extents.

If you comment out that line in matplotlib/axes.py, your example will
work.

Note that I find it a bit more natural to define separate axes to hold
the separate images.  Of course, my approach won't work if you want to
plot other data, eg lines, that cover multiple images on the same
axes, but for simple montages, I think it's cleaner.

    import matplotlib.matlab as mat
    myImage = mat.imread('test1.png')
    myImage2 = mat.imread('test2.png')
    ax1 = mat.axes([0.5, 0.5, 0.5, 0.5])
    ax1.imshow(myImage)
    mat.axis('off')
    ax2 = mat.axes([0, 0.0, 0.5, 0.5])
    ax2.imshow(myImage2)
    mat.axis('off')
    mat.show()

JDH

[Matplotlib-users] markerfacecolor, imshow

[Jon P. <Jon...@no...>]

Hi there

I just recently upgraded my copy of matplotlib to 0.61 (from 0.54!) and 
have found a couple of my scripts no longer working. It seems that, for 
plot(), the argument markerfacecolor no longer takes a color triplet, 
but requires a string ('w', 'k' etc). markerEDGEcolor is still happy to 
take either form of color descriptor.


On a different topic, imshow() only seems to display a single image at a 
time.
e.g. in the following example, when image2 is drawn image1 is deleted.
#-------------------------------------------------
import matplotlib.matlab as mat
myImage = mat.imread('image1.png')
myImage2 = mat.imread('image2.png')
mat.imshow(myImage, extent=[0,1,0,1])
mat.imshow(myImage2, extent=[1,2,1,2])
mat.axis([0, 2, 0, 2])
mat.show()
#-------------------------------------------------
Is that a known issue? Is there a workaround?

all the best,
Jon

This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [Matplotlib-users] default error bar color

[Gregory L. <gre...@ff...>]

Hi,

I think this ordering is an excellent idea! In fact, I also prefer
zorder, or maybe height, or simply z: This can be seen as a
z-coordinate, whose only effect would be to change ordering for a 2D
plot, but could leads to 3D plots in the future :-)

> > Should large numbers
> > be drawn last or first (last is my instinct, like list indexing, and
> > more efficient since you won't have to reverse the sort).
> 
> No preference.

Large number printed last, consistent with the zorder = 3rd coordinate
idea if one look the plot from above.

> > What is a
> > good attribute name?  I think a method like scale_buoyancy would be
> > useful too so users wouldn't have to know the default values.
> 
> zorder or layer

or height...


Best regards,

Greg.

Re: [Matplotlib-users] default error bar color

[Gary R. <ga...@em...>]

Just some comments below as requested

----- Original Message -----
From: John Hunter <jdh...@ac...>

> Isn't this debatable?  Might someone want to see the errorbar range in
> front of or behind a large marker with transparency?  Why do you say
> this with certainty?

You're right John. Personally, I think the default order should be for ma=
rkers to be in front of errorbars, but on occasions I've wanted it the ot=
her way (the current implementation). I like your bouyancy idea. If you'r=
e after a different name, how about the more conventional "z-order".

> It's so easy to do that I could implement it faster than I can
> describe it, but I think buoyancy is a bad name (too hard to spell),
> and I wanted to get some feedback on the idea.  Should large numbers
> be drawn last or first (last is my instinct, like list indexing, and
> more efficient since you won't have to reverse the sort).

No preference.

> What is a
> good attribute name?  I think a method like scale_buoyancy would be
> useful too so users wouldn't have to know the default values.

zorder or layer

regards,
Gary
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Matplotlib-users] default error bar color

[John H. <jdh...@ac...>]

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> When using the errorbar(), I have no way to change the
    Jin-chung> marker size (except do a separate plot()).  Should we
    Jin-chung> add that to the errorbar's argument list?

Hi Jin-chung,

You can change the marker size with 

  1 >>> l, el = errorbar(x, y, fmt='ro',yerr=yerr)
  2 >>> set(l, ms=12)

The first return arg of errorbar is the marker line, and the second
the errorbar lines.  Abbreviations in the kwargs (eg ms for
markersize) were introduced in 0.61.

    Jin-chung> Also there is another inconsistency between plot() and
    Jin-chung> errorbar(), the latter needs the fmt argument, but the
    Jin-chung> former does not recognize it.

The fact that plot doesn't recognize fmt as a kwarg stems from the
fact that it uses positional args for multiple lines and kwargs to set
line properties.  The fact that you can do anf of the following and
more

    a.plot(x,y)            # plot Numeric arrays y vs x
    a.plot(x,y, 'bo')      # plot Numeric arrays y vs x with blue circles
    a.plot(y)              # plot y using x as index array 0..N-1
    a.plot(y, 'r+', antialiased=False, alpha=0.5)
    a.plot(x1, y1, 'g^', x2, y2, 'ro')        # arbitrary number of lines
    a.plot(x1, y1, x2, y2, 'g-', linewidth=2) # w/ or w/o fmt strings

means plot is already stretched to its limit in processing variable
numbers and types of arguments!  All kwargs are assumed to be line set
methods, and Line2D doesn't have a set_fmt method.  The line class
doesn't know about format strings.

    Jin-chung> Another comment about errorbar() is that the error bar
    Jin-chung> should not show in the marker face area, i.e the error
    Jin-chung> bars should be drawn first and then the markers with no
    Jin-chung> transparency.

Isn't this debatable?  Might someone want to see the errorbar range in
front of or behind a large marker with transparency?  Why do you say
this with certainty?

I agree there is a serious limitation in the way the axes draws it
objects - it's too rigid.  The following order is used: frame, images,
axis, patches, lines, text, title, legend, table.

I've been thinking about how to fix this and I think it will be easy.
Assign a buoyancy to each Artist (Line2D, Text, Rectangle, etc are all
derived from Artist).  The higher the buoyancy, the greater the
tendency to float to the top.  Choose defaults in the range of 0..10
(or some other range), and assign default numbers like

  frame   : 2
  images  : 2.5
  axis    : 3 
  patches : 4  (rectangles, polygons and such)
  lines   : 5
  text    : 6
  title   : 7   and so on

The user, of course, could override the number for any object.  Eg

    markerline, errlines = errorbar(*args)
    set(markerline, buoyancy=5.5)   # move it up a little
    set(errlines,   buoyancy=4.5)   # move it down a little

Because all the artists have the same drawing signature, it would be
easy to put them in a list of ( buoyancy, artist) tuples, sort them,
and draw them all.  This would give you the ability to control the
rendering order.

It's so easy to do that I could implement it faster than I can
describe it, but I think buoyancy is a bad name (too hard to spell),
and I wanted to get some feedback on the idea.  Should large numbers
be drawn last or first (last is my instinct, like list indexing, and
more efficient since you won't have to reverse the sort).  What is a
good attribute name?  I think a method like scale_buoyancy would be
useful too so users wouldn't have to know the default values.  Eg, in
the marker example you could scale the buoyancy of the errorlines by
0.9 and the marker lines by 1.1.  Any thoughts?

Once this structure is in place, it would be easy to change the
default order of errorbar and marker on the plot.  But I would like
some defense of the idea that the order you propose is the right one,
and/or input from others.

    Jin-chung> In 0.61.0, the marker edge color is still black,
    Jin-chung> instead of being the same as the marker face color.
    Jin-chung> Personally, I think they should be the same.  What do
    Jin-chung> people think?

    Jin-chung> One reason for the same color argument is that if the
    Jin-chung> markersize is set to a small value, it will show mostly
    Jin-chung> the edge color.

    Jin-chung> One possible reason against it is that if the marker
    Jin-chung> color is white (or whatever the background color is),
    Jin-chung> then you can't see the marker.  But we can default this
    Jin-chung> case to black (or whatever).

I tend to prefer the black marker edge color - I think it looks a
little better.  I'm willing to be persuaded.  Note that for regular
plot commands (not yet for errorbar) you can do

  plot(x, y, 'bo', mec='b') 

I would like to support 'lines.markeredgecolor : None' in rc, but None
is already doing double duty in the Line2D constructor and means "use
the rc value".  I could introduce a new value 'Same' or the string
'None' as opposed to the symbol None for this purpose, or something to
that effect.

For errorbars, since they don't accept all the kwargs that plot
does (the situation is more complex since you have the markers and the
error lines) you have to use the

  1 >>> l, el = errorbar(x, y, fmt='ro',yerr=yerr)
  2 >>> set(l, mec='r', ms=12)

incantation.

    Jin-chung> In 0.61.0, when plotting a simple array with error
    Jin-chung> bars, the default color of the error bars is black,
    Jin-chung> instead of being the same as the line/markers color,
    Jin-chung> e.g.:

    >>>> errorbar([1,2,3,4,5],[3,4,5,6,7],fmt='ro',yerr=[1,1,1,1,1])

    Jin-chung> I prefer them to be the same, especially since the
    Jin-chung> default color for marker/line is blue and a beginner
    Jin-chung> may be surprised to see the different color.

Fixed in CVS.  The ecolor param defaults to None, in which case the
marker color is used.  You can override this by specifying an ecolor
value.

Thanks for the comments,
JDH

[Matplotlib-users] default error bar color

[Jin-chung H. <hs...@st...>]

In 0.61.0, when plotting a simple array with error bars, the default color of 
the error bars is black, instead of being the same as the line/markers color, 
e.g.:

>>> errorbar([1,2,3,4,5],[3,4,5,6,7],fmt='ro',yerr=[1,1,1,1,1])

I prefer them to be the same, especially since the default color for marker/line 
is blue and a beginner may be surprised to see the different color.

This may be related to my last posting regarding the (default) marker edge 
color.

JC Hsu

[Matplotlib-users] marker edge default color

[Jin-chung H. <hs...@st...>]

In 0.61.0, the marker edge color is still black, instead of being the same as 
the marker face color.  Personally, I think they should be the same.  What do 
people think?

One reason for the same color argument is that if the markersize is set to a 
small value, it will show mostly the edge color.

One possible reason against it is that if the marker color is white (or whatever 
the background color is), then you can't see the marker.  But we can default 
this case to black (or whatever).

JC Hsu

[Matplotlib-users] need markersize argument in errorbar function

[Jin-chung H. <hs...@st...>]

Hi John:

When using the errorbar(), I have no way to change the marker size (except do a 
separate plot()).  Should we add that to the errorbar's argument list?

Also there is another inconsistency between plot() and errorbar(), the latter 
needs the fmt argument, but the former does not recognize it.

Another comment about errorbar() is that the error bar should not show in the 
marker face area, i.e the error bars should be drawn first and then the markers 
with no transparency.

JC Hsu

Re: [Matplotlib-users] eps font finding problem on WinXP (?)

[Gary P. <pa...@in...>]

----- Original Message ----- 
From: "John Hunter" <jdh...@ac...>



> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
> 
>     Gary> I've poked around the docs and archives, for a clue to this,
>     Gary> but if it's there I didn't recognize it.
> 
>     Gary> version: 0.62 WinXP default backend: TkAgg interactive (with
>     Gary> ipython)
> 
> Hi Gary, just to make sure we're clear.  The last version of
> matplotlib released was 0.61.0.  Is this what you mean, or are you
> using CVS?

0.61.0   (my typo)

> 
>     Gary> On computer A I have version 0.54 installed.  There I can
>     Gary> create a plot and say savefig('plot.eps') and get a good eps
>     Gary> file.
> 
>     Gary> On computer B I have version 0.62 installed.  There I can
>     Gary> create a plot and say savefig('plot.eps') with different
>     Gary> results: ghostscript chokes.
> 
> There is a known bug in the ps backend on win32 that was discussed
> here a couple of weeks ago.  Fortunately, it has a trivial fix.  In
> site-packages/matplotlib/backends/backend_ps.py, in the encodeTTFasPS
> function, replace the line
> 
>     font = file(fontfile)
> 
> with
> 
>     font = file(fontfile, 'rb')
> 
> Windows cares a lot about that binary flag.
> 
> Please let me know if this cures what ails you, because we are getting
> ready to release the next matplotlib version and I hate to release
> code with known bugs.

That was it.  Problem solved.

I remember that thread now.  It didn't sink in at the time.   Thanks,  Gary


> 
> Thanks!
> JDH

Re: [Matplotlib-users] eps font finding problem on WinXP (?)

[John H. <jdh...@ac...>]

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:

    Gary> I've poked around the docs and archives, for a clue to this,
    Gary> but if it's there I didn't recognize it.

    Gary> version: 0.62 WinXP default backend: TkAgg interactive (with
    Gary> ipython)

Hi Gary, just to make sure we're clear.  The last version of
matplotlib released was 0.61.0.  Is this what you mean, or are you
using CVS?

    Gary> On computer A I have version 0.54 installed.  There I can
    Gary> create a plot and say savefig('plot.eps') and get a good eps
    Gary> file.

    Gary> On computer B I have version 0.62 installed.  There I can
    Gary> create a plot and say savefig('plot.eps') with different
    Gary> results: ghostscript chokes.

There is a known bug in the ps backend on win32 that was discussed
here a couple of weeks ago.  Fortunately, it has a trivial fix.  In
site-packages/matplotlib/backends/backend_ps.py, in the encodeTTFasPS
function, replace the line

    font = file(fontfile)

with

    font = file(fontfile, 'rb')

Windows cares a lot about that binary flag.

Please let me know if this cures what ails you, because we are getting
ready to release the next matplotlib version and I hate to release
code with known bugs.

Thanks!
JDH

[Matplotlib-users] eps font finding problem on WinXP (?)

[Gary P. <pa...@in...>]

I've poked around the docs and archives, for a clue to this, but if it's
there I didn't recognize it.

version:  0.62
WinXP
default backend:  TkAgg
interactive  (with ipython)

On computer A I have version 0.54 installed.  There I can create a plot and
say
savefig('plot.eps')
and get a good eps file.

On computer B I have version 0.62 installed.  There I can create a plot and
say
savefig('plot.eps')
with different results: ghostscript chokes.

In the case of computer A, the eps file contains
/NewCenturySchlbk-Roman findfont
while in the case of computer B, the file contains instead
/BitstreamVeraSerif-Roman findfont

both have TTFPATH=c:\windows\fonts

it's *possible* (I don't remember exactly) that I installed 0.61 from a
windows installer, and 0.54 from setup.py.

afaik, the .matplotlibrc are the same (at least in the font section)
computer B contains a file .ttffile.cache, while computer A does not have
this file
Removing it from B doesn't make any difference.

any idea ... ?

-gary

Re: [Matplotlib-users] Re: WXAgg access violation

[Mark H. <ao...@ds...>]

Hi,

> I thing the crash and the shear effect are both part of the same bug
> that arose from a floating point error in converting figure units to
> width and height.  I believe this is a simple fix.  I was able to
> replicate both of the buggy behaviors on my winxp box, and the
> following change fixed both.  Perhaps you and Heiko can test on your
> respective scripts and let me know.

I can confirm that this fix works for me too. Thanks, that's a big help!

 > Know if I can just figure out why there is the irritating flicker on
 > resizes in win32...

The flicker doesn't seem so bad to me, to be honest. It seemed worse 
because I was using embedding_in_wx4 (which has an extra EVT_PAINT redraw).

Mark

Re: [Matplotlib-users] Re: WXAgg access violation

[Heiko H. <he...@hh...>]

John Hunter wrote:

>Thanks for the bug reports,
>
>I thing the crash and the shear effect are both part of the same bug
>that arose from a floating point error in converting figure units to
>width and height.  I believe this is a simple fix.  I was able to
>replicate both of the buggy behaviors on my winxp box, and the
>following change fixed both.  Perhaps you and Heiko can test on your
>respective scripts and let me know.
>
>On site-packages/matplotlib/backends/backend_wxagg.py, replace
>FigureCanvasWXAgg.draw with
>
>    def draw(self):
>        """
>        Render the figure using agg
>        """
>        DEBUG_MSG("draw()", 1, self)
>
>        FigureCanvasAgg.draw(self)
>        s = self.tostring_rgb()  
>        w = int(self.renderer.width)
>        h = int(self.renderer.height)
>        image = wxEmptyImage(w,h)
>        image.SetData(s)
>        self.bitmap = image.ConvertToBitmap()
>        self.gui_repaint()
>
>Let me know!
>
>Know if I can just figure out why there is the irritating flicker on
>resizes in win32....
>
>JDH        
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>  
>
Hello John,

I tested the fix and the problem seems to be gone. I will continue the 
testing and will let you know in case I will find anything else.

Thank you for your fast response and for the great library..

Heiko

Re: [Matplotlib-users] Re: WXAgg access violation

[John H. <jdh...@ac...>]

>>>>> "Mark" == Mark Howson <ao...@ds...> writes:

    Mark> BTW, the embedding_in_wx4 example (among others) exhibits
    Mark> the same problem for me. I can always reproduce it by
    Mark> launching and resizing the window from small to large,
    Mark> without ever releasing the mouse button. This usually
    Mark> crashes within 10 resizes or so, but as with your
    Mark> description it's intermittent, it can take longer. This is
    Mark> with Windows XP, Python 2.3.4, matplotlib 0.61.0, wxPython
    Mark> 2.5.2.7. It was also present in the last matplotlib and
    Mark> wxPython releases at least. I seem to remember the plain wx
    Mark> frontend also being flaky under this kind of 'abuse', but I
    Mark> can't seem to get that to break now.

    Mark> I also notice that you get a shear effect on some of the
    Mark> resizes (where the plot is drawn as a parallelogram). That's
    Mark> reproducible by shrinking the plot very small, but also
    Mark> occasionally happens at other sizes. I can't be sure whether
    Mark> the size/aspect ratio of the window causes that.

Thanks for the bug reports,

I thing the crash and the shear effect are both part of the same bug
that arose from a floating point error in converting figure units to
width and height.  I believe this is a simple fix.  I was able to
replicate both of the buggy behaviors on my winxp box, and the
following change fixed both.  Perhaps you and Heiko can test on your
respective scripts and let me know.

On site-packages/matplotlib/backends/backend_wxagg.py, replace
FigureCanvasWXAgg.draw with

    def draw(self):
        """
        Render the figure using agg
        """
        DEBUG_MSG("draw()", 1, self)

        FigureCanvasAgg.draw(self)
        s = self.tostring_rgb()  
        w = int(self.renderer.width)
        h = int(self.renderer.height)
        image = wxEmptyImage(w,h)
        image.SetData(s)
        self.bitmap = image.ConvertToBitmap()
        self.gui_repaint()

Let me know!

Know if I can just figure out why there is the irritating flicker on
resizes in win32....

JDH        

[Matplotlib-users] Re: WXAgg access violation

[Mark H. <ao...@ds...>]

Hi,

> I'm getting access violations while resizing the window/splitters of the 
> attached script. The problem is intermittant.

BTW, the embedding_in_wx4 example (among others) exhibits the same 
problem for me. I can always reproduce it by launching and resizing the 
window from small to large, without ever releasing the mouse button. 
This usually crashes within 10 resizes or so, but as with your 
description it's intermittent, it can take longer. This is with Windows 
XP, Python 2.3.4, matplotlib 0.61.0, wxPython 2.5.2.7. It was also 
present in the last matplotlib and wxPython releases at least. I seem to 
remember the plain wx frontend also being flaky under this kind of 
'abuse', but I can't seem to get that to break now.

I also notice that you get a shear effect on some of the resizes (where 
the plot is drawn as a parallelogram). That's reproducible by shrinking 
the plot very small, but also occasionally happens at other sizes. I 
can't be sure whether the size/aspect ratio of the window causes that.

[Matplotlib-users] WXAgg access violation

[Heiko H. <he...@hh...>]

Hello,

I'm getting access violations while resizing the window/splitters of the 
attached script. The problem is intermittant.

Windows XP
Python 2.3.3
matplotlib 0.61.00 (.matplotlibrc from examples)
wxPython *2.5.2.7

Any idea what's going on?

Heiko

*

[Matplotlib-users] ipython, gtk & matplotlib support; end of current ipython development

[Fernando P. <Fer...@co...>]

Hi everyone,

sorry for the cross post to those of you who are on all these lists, but since 
this will affect ipython's future quite a bit, I want a significant heads-up 
to be seen by all potentially affected.

1. PyGTK & matplotlib
---------------------

Thanks to Antoon Pardon and John Hunter, ipython has nearly ready full support 
for interactive matplotlib with all backends.  In this process, we've also 
added GTK threading support, so you can now use ipython for pygtk development.

This code is now in IPython's CVS, and the matplotlib features require 
matplotlib CVS (for matplotlib use only; matplotlib has NOT become a general 
ipython requirement).  So those of you willing to bleed a little can use it, 
and now is your opportunity to let us know of any problems you find.

Our solution is simpler, but more limited in scope, than scipy's gui_thread. 
However it currently does NOT work with the WX backends, only with Tk and GTK 
(-AGG or not).  Help from any WX guru is welcome, the place to look is at the 
end of IPython/Shell.py.  I hope that we can find, at least in our more 
limited context, a working solution for WX which doesn't require all the 
complexity of gui_thread.

In order to use this, do an 'ipython -upgrade' after a cvs update; this will 
get the necessary support files into ~/.ipython.  You will then need to use 
the new threading options; copying from the docs:

  -gthread, -mpthread: these are special options, only one of which can be
  given, and which can ONLY be given as the FIRST option passed to IPython
  (they will have no effect in any other position).

  If -gthread is given, IPython starts running a separate thread for GTK
  operation, so that pyGTK-based programs can open GUIs without blocking
  IPython.

  The -mpthread option adds special support for the matplotlib library
  (http://matplotlib.sourceforge.net), allowing interactive usage of the GTK
  and WX backends.  This also modifies the @run command to correctly execute
  any matplotlib-based script which calls show() at the end, without blocking.

The most convenient way to use this is the new pylab profile, which should be 
invoked as follows (aliasing this in your shell may be a good idea):

	$ ipython -mpthread -p pylab

pylab will honor your choice of matplotlib backend, though currently it will 
revert (with a warning) WX to TkAgg, since WX is broken.  This will go away 
once we figure out the WX problems.


2. IPython's future
-------------------

Once this support for matplotlib is working to satisfaction, it will mean the 
end of the line for any more feature-related changes to ipython for quite a 
while.  Once this is reasonably shaken (I hope with at most one more release 
beyond 0.6.3, which will officially include this), I plan on beginning the 
long-awaited internal cleanup of ipython.

Given my very limited time, this will mean essentially ZERO new features on 
ipython for quite a while.  It will also mean that the new ipython will:

- require python 2.3: I want to deprecate as much redundant code as I can from 
the ipython distribution.  I'll use optparse and any other new module from the 
stdlib which can help shrink ipython.

- break backwards compatibility in many areas.  In particular, the ipythonrc 
files will become true python files.

- the internal class structure of ipython will drastically change.  If you 
have code which uses ipython via IPython.Shell, you should be fine, as I'll 
try to keep that API stable.  If you've been poking your dirty fingers into 
iplib or ipmaker directly, expect things to break badly, and don't even think 
about complaining :)

Hopefully once this is over, it will mean having a much cleaner ipython, with 
an easy path for including it into GUI shells (such as pycrust), and a sane 
internal code structure.  As the new design shakes down, we'll eventually have 
an ipython 1.0 at last ;)

Because of these changes coming down the pipe, if you have any further patches 
or changes for the current ipython which you'd like to see included, please 
send them NOW to me.  Once I shift gears to the cleanup project, I'll 
unfortunately have to drop most changes not going in that direction, simply 
for lack of time.

I'd like to thank everybody who has contributed to ipython's development so 
far, and to encourage others to join in.  The cleanup should not be too hard, 
and it will open the door for having ipython as the interactive core for very 
high quality python-based environments in the future.

Best regards,

f

Re: [Matplotlib-users] Y-Axis scaling bug?

[Karl-Heinz G. <gl...@kh...>]

Hallo John,

John Hunter wrote:

> Hi Karl, thanks for the report.  Darren Dale noted this problem and
> posted a patch to fix it.  If you have CVS access, it should be fixed
> there.  

Thanks a lot. I tried Darrens fix and it works perfectly now.

Kalle.

Re: [Matplotlib-users] Y-Axis scaling bug?

[John H. <jdh...@ac...>]

>>>>> "Karl-Heinz" == Karl-Heinz Glahe <gl...@kh...> writes:

    Karl-Heinz> Hallo, it seems to me that the scaling of the Y-axis
    Karl-Heinz> gets wrong if the y-values are below 1e-4. (Release
    Karl-Heinz> 0.61.0, OS=Windows 2000 SP4, Python 2.3.4, actual
    Karl-Heinz> wxPython Release) The previous release did not show
    Karl-Heinz> this behavior.

Hi Karl, thanks for the report.  Darren Dale noted this problem and
posted a patch to fix it.  If you have CVS access, it should be fixed
there.  Otherwise, please search the mailing list archives for recent
posts by Darren and you should find the fix.

If his patch (or CVS) does not fix your problem, please let me know.

JDH