wxPyPlot on OSX

I am running wxPythonOSX-2.4.0.7 (Python 2.3a2) on OS X 10.2.4.
When I attempt to run wxPyPlot (the demo) no lines or markers are plotted.
The grid, axes, titles, legends etc. all work fine - but no graphs.

I have seen this behaviour reported by some Linux users also.

Below are some errors that were produced when I ran wxPyPlot. They may have some bearing
on what's going on. I could imagine that if a decimal float is coerced to an int this might produce
an unintended zero and the line is drawn off the viewable window. But since the grid and labels
are OK , this does not seem to be the problem.

Thanks for any help.

Jim

[macjboyle:~/python] boyle% pythonw wxPyPlot.py
09:03:50: Debug: wxMac library installation name is '/usr/local/lib/libwx_macd-2.4.0.dylib'
09:03:50: Debug: wxMac resources file name is '/usr/local/lib/libwx_macd-2.4.0.rsrc'
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/wxPython/gdi.py:570: DeprecationWarning: integer argument expected, got float
   val = apply(gdic.wxDC_DrawText,(self,) + _args, _kwargs)
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/wxPython/gdi.py:561: DeprecationWarning: integer argument expected, got float
   val = apply(gdic.wxDC_DrawRotatedText,(self,) + _args, _kwargs)
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/wxPython/gdi.py:543: DeprecationWarning: integer argument expected, got float
   val = apply(gdic.wxDC_DrawLine,(self,) + _args, _kwargs)
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/wxPython/gdi.py:693: DeprecationWarning: integer argument expected, got float
   val = apply(gdic.wxDC_SetClippingRegion,(self,) + _args, _kwargs)
Left Mouse Down at Point: (2.4017, -0.7089)

boyle5@llnl.gov wrote:

I am running wxPythonOSX-2.4.0.7 (Python 2.3a2) on OS X 10.2.4.
When I attempt to run wxPyPlot (the demo) no lines or markers are
plotted.
The grid, axes, titles, legends etc. all work fine - but no graphs.

I have seen this behaviour reported by some Linux users also.

Hi,

I found the problem on Linux (GTK), and it may be the same on OS-X, I
havn't had the chance to try it there. The problem is in setting the
Clipping Region in

PlotCanvas.Draw()

The coordinates passed in include a negative height, which apparently
GTK doesn't like. In fact, from my experiments, it appears to interpret
the negative height as "clip to outside this rect, instead of inside",
but I didn't go too far with that experimentation. If you add:

        # fix so height is positive: this should probably be done
elsewhere
        if rectHeight < 0:
            pty = pty + rectHeight
            rectHeight = - rectHeight

before:
        
        dc.SetClippingRegion(ptx,pty,rectWidth,rectHeight)

It works fine. That fix should be done more elgantly, but I havn't
figured out the code well enough to figure out where or how.

by the way, on GTK, there is a font problem, which was discussed
recetnly on this list (by me and Robin) I've posted a bug report, but
the work around is to construct the font from scratch, something like
this:

of = Label3.GetFont()
Font = wxFont(int(of.GetPointSize() * 2), of.GetFamily(), wxNORMAL,
wxNORMAL)

(Label3 is a wxStaticText)

I don't have the time to impliment the fix in wxPyPlot now, but I
proboably will in the future.

Another note: in all the drawing code, there are calls like:

       dc.DrawEllipseList(rect.astype(Numeric.Int32))

The conversion to Int32 is not neccessary, you can just do:

       dc.DrawEllipseList(rect)

The conversion will happen anyway. Unfortunately the DrawXXList methods
aren't optimized for Numeric arrays. If theey were then the conversion
might be required. The reason they are not id because I havn't figure
out how to put that optimized code in without requiring Numeric to be
around when compiling and running wxPython, and Robin, quite reasonably,
doesn't want wxPython to dependent on Numeric. If NumArray ever makes it
into the Python standard libary, we could add that code.

-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

Chris.Barker@noaa.gov

Chris,

I applied your change to make the height always positive, and all looks fine so far.

I 've been looking for a lightweight, native, plotting system for OS X and this
might be it.

Many Thanks.
Jim

Hi Chris,

I have made the changes so that height and width are always positive. I
hope this will fix the problem with Linux and Mac. I don't know if Windows
has the correct behavior or the others do, but I guess they are different :frowning:

With

       dc.DrawEllipseList(rect.astype(Numeric.Int32))

the conversion to int runs about 15% faster so that is why I do it.

Lastly

of = Label3.GetFont()
Font = wxFont(int(of.GetPointSize() * 2), of.GetFamily(), wxNORMAL,
wxNORMAL)

This is not good. Is there a font type that I can default to that will work
as expected on Linux without going thought this mess. Is it only the
wxScript that causes the problem that I use in the demo or is it everywhere?
Any idea how fast it will be fixed?

Regards,

Gordon Williams

···

----- Original Message -----
From: "Chris Barker" <Chris.Barker@noaa.gov>
To: <wxPython-users@lists.wxwindows.org>; "Gordon Williams"
<g_will@cyberus.ca>
Sent: Wednesday, April 02, 2003 2:51 PM
Subject: Re: [wxPython-users] wxPyPlot on OSX

boyle5@llnl.gov wrote:
>
> I am running wxPythonOSX-2.4.0.7 (Python 2.3a2) on OS X 10.2.4.
> When I attempt to run wxPyPlot (the demo) no lines or markers are
> plotted.
> The grid, axes, titles, legends etc. all work fine - but no graphs.
>
> I have seen this behaviour reported by some Linux users also.

Hi,

I found the problem on Linux (GTK), and it may be the same on OS-X, I
havn't had the chance to try it there. The problem is in setting the
Clipping Region in

PlotCanvas.Draw()

The coordinates passed in include a negative height, which apparently
GTK doesn't like. In fact, from my experiments, it appears to interpret
the negative height as "clip to outside this rect, instead of inside",
but I didn't go too far with that experimentation. If you add:

        # fix so height is positive: this should probably be done
elsewhere
        if rectHeight < 0:
            pty = pty + rectHeight
            rectHeight = - rectHeight

before:

        dc.SetClippingRegion(ptx,pty,rectWidth,rectHeight)

It works fine. That fix should be done more elgantly, but I havn't
figured out the code well enough to figure out where or how.

by the way, on GTK, there is a font problem, which was discussed
recetnly on this list (by me and Robin) I've posted a bug report, but
the work around is to construct the font from scratch, something like
this:

of = Label3.GetFont()
Font = wxFont(int(of.GetPointSize() * 2), of.GetFamily(), wxNORMAL,
wxNORMAL)

(Label3 is a wxStaticText)

I don't have the time to impliment the fix in wxPyPlot now, but I
proboably will in the future.

Another note: in all the drawing code, there are calls like:

       dc.DrawEllipseList(rect.astype(Numeric.Int32))

The conversion to Int32 is not neccessary, you can just do:

       dc.DrawEllipseList(rect)

The conversion will happen anyway. Unfortunately the DrawXXList methods
aren't optimized for Numeric arrays. If theey were then the conversion
might be required. The reason they are not id because I havn't figure
out how to put that optimized code in without requiring Numeric to be
around when compiling and running wxPython, and Robin, quite reasonably,
doesn't want wxPython to dependent on Numeric. If NumArray ever makes it
into the Python standard libary, we could add that code.

-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

Chris.Barker@noaa.gov

Gordon Williams wrote:

I have made the changes so that height and width are always positive. I
hope this will fix the problem with Linux and Mac. I don't know if Windows
has the correct behavior or the others do, but I guess they are different :frowning:

yup. the negative height is kind of handy, too bad it's not supported
everywhere.

With
> dc.DrawEllipseList(rect.astype(Numeric.Int32))
the conversion to int runs about 15% faster so that is why I do it.

Wow! that's a big speed up!, particularly since you need to loop through
the coords an extra time, and wxPython treats a NumPy array as a generic
sequence, and thus has to check to make sure all the numbers are ints
anyway. But the proof is in the pudding...

> of = Label3.GetFont()
> Font = wxFont(int(of.GetPointSize() * 2), of.GetFamily(), wxNORMAL,
> wxNORMAL)
>
This is not good. Is there a font type that I can default to that will work
as expected on Linux without going thought this mess.Is it only the
wxScript that causes the problem that I use in the demo or is it everywhere?

Nope. I had the problem with the default font for a StaticText.

Any idea how fast it will be fixed?

No idea at all. Frankly, it's quite remarkable that it's still there,
but X fonts can be tricky.

Thanks for your work on this. I hope to use it, and then I may be able
to work on it some more, it seems to be pretty well put together.

-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

Chris.Barker@noaa.gov