matplotlib-devel Mailing List for matplotlib (Page 553)

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> At least on my platform, it looks as though commenting out
    Jeremy> the line assert self.Ok(), "wxMemoryDC not OK to use" in
    Jeremy> GraphicsContextWx.__init__() solves the problem. I am not
    Jeremy> at all sure why this should be the case.

    Jeremy> I'd be interested to know if this works for you too.

I commented it out (everywhere) and it ran fine.  Apparently it was
hanging ...

  Two quick observations - 

   - figtext renders a completely black screen
   - vertical text still broken 

Otherwise the figures look fantastic!

JDH

On Tuesday 02 December 2003 8:29 pm, Jeremy O'Donoghue wrote:
>
> I'm seeing a failure with one of my asserts, so I'll start there. Should
> have more info shortly.

At least on my platform, it looks as though commenting out the line
assert self.Ok(), "wxMemoryDC not OK to use"
in GraphicsContextWx.__init__() solves the problem. I am not at all sure
why this should be the case.

I'd be interested to know if this works for you too.

Just running through the regression suite on Linux to make sure there are no 
other oddities.

Regards

Jeremy

On Tuesday 02 December 2003 6:22 pm, John Hunter wrote:
> >>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
>
>     Jeremy> I have attached the updated backend_wx.py. Obviously if
>     Jeremy> I've broken wxGTK I'll need to look into it as a matter of
>     Jeremy> urgency.
>
> Probably is a GTK2 thing.  Do you have access to a GTK2 machine to
> test?

Don't have access to a GTK2 version of wxPython...
But I've just diagnosed the same problem on my Linux box. Since the code 
worked this morning, I probably haven't broken much, but these wxMemoryDC 
calls really don't behave quite the same way on Windows and GTK.

I'm seeing a failure with one of my asserts, so I'll start there. Should have 
more info shortly.

Regards

Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I have attached the updated backend_wx.py. Obviously if
    Jeremy> I've broken wxGTK I'll need to look into it as a matter of
    Jeremy> urgency.

Probably is a GTK2 thing.  Do you have access to a GTK2 machine to
test?

    Jeremy> This sounds worryingly as though you do have the latest
    Jeremy> version (there was no file save dialog code at all until
    Jeremy> this morning).

Yep, same problem with the attached code.

    Jeremy> In particular, the behaviour of a wxMemoryDC (which is the
    Jeremy> context used to draw into the bitmap) seems quite
    Jeremy> different between the two platforms. The main bug I've had
    Jeremy> to deal with is that the bitmap can only be selected into
    Jeremy> a single wxMemoryDC at a time. This means that I have to
    Jeremy> take explicit care to ensure that whenever a
    Jeremy> GraphicsContextWx.new_gc() is called, I explicitly ensure
    Jeremy> that the bitmap is selected from the last wxMemoryDC.

I diagnosed why the print code doesn't save a file.  It hangs
indefinitely on the call to

  gc = self.drawable.new_gc()

    Jeremy> The other thing to look for is in the _onSize and _onPaint
    Jeremy> methods of FigureWx: the image from the bitmap is sent to
    Jeremy> the screen with a Blit() call. This seems to be necessary
    Jeremy> on Windows as the (simpler, but equivalent) DrawBitmap()
    Jeremy> call does not work properly.

Tried Blit versus DrawBitmap in both.  No help

    Jeremy> Where the printing is concerned, again, you could try
    Jeremy> uncommenting the 'self.bitmap.SaveFile()' line, which
    Jeremy> checks whether it is possible to save a 'known good'
    Jeremy> bitmap.

No help, due to the hang on new_gc

Any other ideas?

JDH

Hi John,

John Hunter said:
>
[snip]
>
> One minor glitch.  I just did an update to backend_wx Repository
> revision: 1.15.  When I launch a figure, eg
>
>  > python subplot_demo.py -dWX
>
> The window comes up and looks properly placed and sized, but no image
> appears in the figure window.  I have the window, the toolbar etc,
> only no axes, no plot.  Hmmm....  RHL9, GTK2, wxPythonSrc-2.4.2.4.

I hope not. I haven't yet fully regression tested on Debian (a job for
tonight), but I'd be surprised as all seemed OK in Linuxland this morning
(barring a few glitches in the figure saving code).

I have attached the updated backend_wx.py. Obviously if I've broken wxGTK
I'll need to look into it as a matter of urgency.

> When I click on the save dialog, it pops up, prompts me for a
> filename, and then does noting -- no file is created.
> Perhaps I have the older version of backend_wx (sometimes the CVS
> mirrors are behind).  If so, please send me the attachment.

This sounds worryingly as though you do have the latest version (there wa=
s
no file save dialog code at all until this morning).

> Otherwise, if you have any insights, please let me know.

I have noticed that the behaviour of wxPython when using bitmaps is
slightly different between Windows and GTK. My own machine has wxPython
linked against GTK 1.2 (I think) so there may be some differences there.

In particular, the behaviour of a wxMemoryDC (which is the context used t=
o
draw into the bitmap) seems quite different between the two platforms. Th=
e
main bug I've had to deal with is that the bitmap can only be selected
into a single wxMemoryDC at a time. This means that I have to take
explicit care to ensure that whenever a GraphicsContextWx.new_gc() is
called, I explicitly ensure that the bitmap is selected from the last
wxMemoryDC.

The other thing to look for is in the _onSize and _onPaint methods of
FigureWx: the image from the bitmap is sent to the screen with a Blit()
call. This seems to be necessary on Windows as the (simpler, but
equivalent) DrawBitmap() call does not work properly.

You may (as a matter of interest) want to try going to around line 712,
where, just under the call to drawDC.Blit() there is a call to
drawDC.DrawBitmap() which is commented out. Comment the call to Blit() an=
d
uncomment DrawBitmap() (they are equivalent) and see if the figure appear=
s
on screen.

Where the printing is concerned, again, you could try uncommenting the
'self.bitmap.SaveFile()' line, which checks whether it is possible to sav=
e
a 'known good' bitmap.

These may give some insights if there is unexpected platform-specific
behaviour. You'll notice that I have put quite a few 'assert' statements
in the low-level code to try to trap this sort of thing.

>     Jeremy> I should note that performance of the double-buffered
>     Jeremy> drawing backend is not as good as the previous GDI version
>     Jeremy> (at least on Windows), although animated drawing will be
>     Jeremy> flicker-free. I would be interested to hear opinions on
>     Jeremy> whether people prefer double buffered drawing or GDI, and
>     Jeremy> whether it makes sense to support both (as an option when
>     Jeremy> creating a figure, perhaps).
>
> If it's not hard to support both, why not.  I prefer flicker free
> navigation and animation over performance, and in most cases find the
> performance of matplotlib acceptable (pcolor being a notable
> exception).  But I have a fast machine.

It's not too hard to support both - I'd have to go and rescue some of the
old code, and rethink (again) how to support wxDC classes in
GraphicsContextWx (as I'd have to support three different types)

>     Jeremy> John, is it worth activiating the Sourceforge bug tracker
>     Jeremy> after 0.4 release?
>
> I think it is active.  There have been 4 bug reports and 1 patch there
> already.  I'm willing to go either way here.  I find it easier to
> check the mail list than the SF site, but I can train myself otherwise
> if you think it's worthwhile to do so.

I'm happy with either, although users may prefer the bug list - especiall=
y
given the lamentable performance of SF in archiving matplotlib-devel,
which make it difficult for the casual user to browse the list of known
bugs before reporting new ones.

Let me know how you get on. I'll look hard at things on my Linux box late=
r.

Regards

Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I have just committed a significant update to backend_wx.
    Jeremy> The intention is that this will be the basis of the
    Jeremy> backend_wx code in release 0.40 of Matplotlib. It contains
    Jeremy> numerous small fixes, but the highlights are:

Hi Jeremy, 

This sounds great.  It looks like everything is about ready to go.

One minor glitch.  I just did an update to backend_wx Repository
revision: 1.15.  When I launch a figure, eg

 > python subplot_demo.py -dWX

The window comes up and looks properly placed and sized, but no image
appears in the figure window.  I have the window, the toolbar etc,
only no axes, no plot.  Hmmm....  RHL9, GTK2, wxPythonSrc-2.4.2.4.

When I click on the save dialog, it pops up, prompts me for a
filename, and then does noting -- no file is created.

Perhaps I have the older version of backend_wx (sometimes the CVS
mirrors are behind).  If so, please send me the attachment.

Otherwise, if you have any insights, please let me know.

    Jeremy> I should note that performance of the double-buffered
    Jeremy> drawing backend is not as good as the previous GDI version
    Jeremy> (at least on Windows), although animated drawing will be
    Jeremy> flicker-free. I would be interested to hear opinions on
    Jeremy> whether people prefer double buffered drawing or GDI, and
    Jeremy> whether it makes sense to support both (as an option when
    Jeremy> creating a figure, perhaps).

If it's not hard to support both, why not.  I prefer flicker free
navigation and animation over performance, and in most cases find the
performance of matplotlib acceptable (pcolor being a notable
exception).  But I have a fast machine.

    Jeremy> Known bugs are:

    Jeremy>  - Mousewheel (on Windows) only works after menu button
    Jeremy> has been pressed at least once. I do not plan to fix this
    Jeremy> since John is planning to rewrite the navigation code for
    Jeremy> backend_gtk to work more like matlab.

    Jeremy>  - Mousewheel on Linux (wxGTK linked against GTK 1.2) does
    Jeremy> not work at all Suspect that this is a GTK 1.2 issue, but
    Jeremy> in any event, it's something else I don't plan to fix.

I'm not too worried about mouse wheel stuff for the first release,
especially with changes to the navigation bar approaching.

    Jeremy> John, is it worth activiating the Sourceforge bug tracker
    Jeremy> after 0.4 release?

I think it is active.  There have been 4 bug reports and 1 patch there
already.  I'm willing to go either way here.  I find it easier to
check the mail list than the SF site, but I can train myself otherwise
if you think it's worthwhile to do so.

JDH

I have just committed a significant update to backend_wx.

The intention is that this will be the basis of the backend_wx code in
release 0.40 of Matplotlib. It contains numerous small fixes, but the
highlights are:

 - Implemented double-buffered drawing
 - GraphicsContextWx now inherits from wxMemoryDC (consequence of double
   buffered drawing)
 - Implemented save to JPEG, Windows BMP, PNG, TIF, PCX, XPM formats
 - Incorrect initial figure window placement on some Unix platforms
 - Mouse wheel (subject to known bug) works in Windows
 - Toolbar button presses cause multiple events on Windows platform
 - Width of figure frame now correct in Windows
 - Figures now respond correctly to resize events
 - Sets self._reset =3D False in AxisTextWx.__set_font() as per info
   from JDH in axes.py
 - figtext.py now works correctly - text attributes retained correctly

I should note that performance of the double-buffered drawing backend is
not as good as the previous GDI version (at least on Windows), although
animated drawing will be flicker-free. I would be interested to hear
opinions on whether people prefer double buffered drawing or GDI, and
whether it makes sense to support both (as an option when creating a
figure, perhaps).

Known bugs are:

 - Mousewheel (on Windows) only works after menu button has been pressed
   at least once. I do not plan to fix this since John is planning to
   rewrite the navigation code for backend_gtk to work more like matlab.

 - Mousewheel on Linux (wxGTK linked against GTK 1.2) does not work at al=
l
   Suspect that this is a GTK 1.2 issue, but in any event, it's something
   else I don't plan to fix.

 - Vertical text renders horizontally if you use a non TrueType font
   on Windows. This is a known wxPython issue. Work-around is to ensure
   that you use a TrueType font.

 - Pcolor demo puts chart slightly outside bounding box (approx 1-2 pixel=
s
   to the bottom left). This issue also exists in backend_gtk (the code
   in this area is substantially the same for both backends)

 - Outputting to bitmap more than 300dpi results in some text being
   incorrectly scaled. Seems to be a wxPython bug on Windows for font
   point sizes > 60, as font size is correctly calculated. Workaround
   is to use DPI <=3D 300. I only found the problem for 360DPI plots.

With the exception of the known bugs above, please report any other issue=
s
via the matplotlib-devel mailing list. I will try to fix them, but in the
meantime, I'm keen to get a Debian package for 0.4 put together.

John, is it worth activiating the Sourceforge bug tracker after 0.4 relea=
se?

Regards

Jeremy

Hi John,

I thought I'd better keep you updated on backend_wx progress, as it's bee=
n
a while since I've checked everything in.

Main reason is that I've been working on the 'savefig' option, which
prompted a decision to move the entire backens, as you suggested, to use
double-buffered drawing.

This has proven slightly more complicated than I at first thought, and I
haven't checked any code in as backend_wx is in a rather worse state than
the current CVS version. This is being dealt with rapidly, however, and
things are now almost back to where they were previously.

The good news is that I've fixed most of the known bugs, and much of the
backend code is now cleaner. I'm targetting getting something into CVS
over the next couple of days, provided that I can get to a point where I'=
m
happy with it on Win32 and Linux platforms (it seems that double bufferin=
g
behaves rather differently on the two platforms, and there have been quit=
e
a few subtlties I've had to work out).

One bug which I don't think will be fixed before 0.40 is mousewheel on
wxGTK - I think this simply doesn't work properly on the version of wxGTK
installed on my Linux box. However, operation of the buttons themselves i=
s
fine.

Anyway, hopefully you should see something in the CVS pretty shortly.

Regards

Jeremy

On Saturday 22 November 2003 3:48 pm, you wrote:
>
[snip]
>
> There are a couple of issues with the wx backend that I've noticed on
> my redhat linux 9 box with wxpython compiled from the src package
> wxPythonSrc-2.4.2.4.  All of these are problems I was having with the
> *last* version of wx you checked in.  I'm at home and can't test the
> latest code since I don't have wx installed here yet.
>
>   1) ylabel (vertical) text is not rendered properly

This works for me on both Windows and GTK ports of wxPython (actually, the 
Linux font handling is better than Windows, to my surprise). I believe that 
my Debian port is linked against GTK 1.x rather than GTK 2.x, which may make 
a difference. If you are using wxMotif, some of the font support is weaker 
than the GTK port, which may be the issue. Hard for me to tell.

>   2) initial figure window placement is still partially off screen

I can fix this with a default window position parameter, but wx is supposed to 
guess this 'intelligently' by default (and does so for me). I'll try a 
default position parameter and see how we go. If you want to see if this 
helps, pass a pos=wxPosition(x,y) default parameter to the call to 
wxFrame.__init__() frame (in FigureFrameWx constructor)

I'll try to get something into the next CVS check-in.

>   3) With a window resize, the figure doesn't seem to resize in
>      correct proportions.  This is something I've experimented only
>      briefly so am not sure.

Haven't noticed this problem (apart from text - I'll look at this when I have 
a moment) - but I'll try a few experiments.

>   4) I've also noticed some pixel rounding error -- eg on the
>      histogram demo.  I have similar problems with the GTK backend and
>      am not sure how to best resolve them.  This tends to not be a
>      problem on high res outputs where a single dot off is less
>      noticeable.

>   5) Do your dashes scale with DPI?  On the GTK, GD and PS backends, I
>      specify dashes with points so the appearance scales with figure
>      resolution.  The whole issue of how things scale with DPI will
>      probably arise when you get the save to hardcopy functionality
>      implemented.  In the eearly release of the GTK backend I did not
>      handle these issues, but they inevitably become important.

I believe that dashes scale, but until I have a higher resolution output I 
won't be sure. In fact, wxPython does have the capability to generate 
user-defined dashes, but I never managed to make it work, and it's very 
poorly documented. I suspect that I may come back to this one later.

>   6) The toolbar is at the top rather than then bottom of the figure.

This was a bug in one particular CVS check-in. I believe that it has gone now, 
although I am having some trouble making a button which responds to 
mousewheel events in a cross platform way - this is curretnly the main 
toolbar issue.

> Overall things are looking very good.  I may spend some time reading
> up on the WX API to see if I can lend a hand on any of these lingering
> issues since I have achieved most of my goals on the frontend side for
> 0.40.  I would like to have the wx backend in a refined state because
> I suspect a lot of wx users will check out the package when we
> announce to the wx mailing list.

I'm pretty busy with other things this week, but I'll try to get preliminary 
graphics export support in place, and a couple of bugfixes (especially the 
toolbar mousewheel problem, which is important).

Regards

Jeremy

I've finally gotten around to committing the changes to backend_wx for
these API changes.

Time has been tight this week, and I haven't been able to thoroughly
regression test, but the code worked for the cases I tried.

I will be doing a more thorough set of tests over the weekend, but in the
meantime, I didn't want backend_wx to stay out of sync for any longer.

Regards

Jeremy

I've added the html docs to the CVS repository.  Anyone who wants to
make additions or changes to the documentation is welcome!

Jeremy, you may want to update the WX stuff as you see fit.

The documentation is generated using a python templating engine.  The
details can be found in htdocs/README.

The documentation in CVS is for the 0.40 release.

John Hunter

>>>>> "Andrew" == Andrew Brehaut <ad...@st...> writes:

    Andrew> Hi, i saw the link to matplotlib on the python url today,
    Andrew> and although i dont use matlab i do use gnuplot for alot
    Andrew> of cosc stuff i do at uni.  `problem' is im getting a mac,
    Andrew> so i might be keen to help port to a cocoa backend. i cant
    Andrew> garuntee anything, but if others offer to help, i will see
    Andrew> if i can throw my support in.

Hi Andrew,

Sorry for the delay in getting back to you.  I didn't see your email
until today when I was sorting through some old mail.

I don't know anything about cocoa but if you are familiar with it and
want to do a backend, by all means!  There may be a couple of
alternatives, though.  pygtk has been ported to os x and there is a
fink package in the unstable distribution
http://fink.sourceforge.net/pdb/section.php/gnome.  If you would like
to be the crash test dummy for the gtk backend on OS X, by all means.
Please let us know what you learn.

The other alternative is to use the wx backend, which was released in
alpha version with matplotlib-0.32 and should be fairly polished in a
couple of weeks.  wxpython now works on OS X -
http://www.wxpython.org/download.php#binaries.  If you decide to go
this route, please report any bugs that are not listed in the KNOWN
BUGS section of the matplotlib/backends/backend_wx.py to
matplotlib-devel mailing list.  As you may know, wx uses native GUI
widgets on the target platform and so should have the look and feel of
a Mac window.

You may want to consider joining the mailing lists -
http://sourceforge.net/mail/?group_id=80706.

Thanks!
John Hunter

>>>>> "Charles" == Charles R Twardy <cha...@in...> writes:

    Charles> On Tue, 18 Nov 2003, John Hunter wrote: JH: JH:Good to
    Charles> hear -- I think the code is becoming much cleaner.  Even
    Charles> I JH:understand the way _matlab_helpers and Gcf works
    Charles> now!

    Charles> I might need a hand there. I had a script that used to
    Charles> use the ShowOn method directly, but that isn't working
    Charles> now, and I'm not quite sure what's the right thing to do.

Is this with CVS or version 0.32?  I just tested the CVS version in
interactive mode (interactive2.py) and it worked; I am not sure right
now what trouble you are having.  I'd like to clear up the bug so let
me know anything you can (version info) and if possible an example
script.  

    Charles> I'm trying to maintain a figure on my own, without having
    Charles> a call to show(). I used to be able to set ShowOn to 1,
    Charles> queue draw events as needed, and update the display every
    Charles> few seconds on my own with calls to gtk_mainiteration().

As a workaround, is it possible to use the backend_gtk Figure class
directly

  from matplotlib.backends_gtk import FigureGTK

  fig = Figure(figsize=(5,4), dpi=100)
  ax = Subplot(fig, 111)    # <<<- new API in CVS

Then you can do away with 'show' and 'ShowOn' altogether and use the
GTK tools directly.  See the embedding_in_gtk.py and
embedding_in_gtk2.py (new in CVS) if you want to use the toolbar.

BTW, excepting the wx backend which Jeremy is still porting to the
last frontend change, CVS is now in very good shape with no known
bugs, and does a much better job of precise layout (ticklabel
positioning, tick sizes, legend placement, etc, by virtue of the new
transform system).  The untrained eye may not notice a difference.  So
if you are not using CVS you may want to consider it (cvs mirror may
need some time to update).  I also would like as much testing as
possible before 0.40.  For users, there are few significant changes

  - figure sizes and relative text sizes will appear different (as
    discussed before) but this is stabilizing.  Eg, I don't anticipate
    significant changes in future releases

  - If you use the OO API directly, init Axes, Subplot with fig
    instances.  If you create your own Line2D, or Rectangle, or other
    artists, you need to init them with a dpi instance, bbox, and x
    and y transformations.  See the header in the transforms module.  

(for a complete list of API changes, see axes.py).  I'll spell this
out in greater detail in the actual release.

JDH

On Tue, 18 Nov 2003, John Hunter wrote:
JH:
JH:Good to hear -- I think the code is becoming much cleaner.  Even I
JH:understand the way _matlab_helpers and Gcf works now!

I might need a hand there. I had a script that used to use the ShowOn
method directly, but that isn't working now, and I'm not quite sure what's
the right thing to do.

I'm trying to maintain a figure on my own, without having a call to
show(). I used to be able to set ShowOn to 1, queue draw events as needed,
and update the display every few seconds on my own with calls to
gtk_mainiteration().

-C

-- 
Charles R. Twardy                    www.csse.monash.edu.au/~ctwardy
Monash University                    sarbayes.org
Computer Sci. & Software Eng.
+61(3) 9905 5823 (w)  5146 (fax)

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I'm not concerned by moving targets - the changes to date
    Jeremy> have been sensible both in improving functionality and
    Jeremy> rationalising the backend design.

Good to hear -- I think the code is becoming much cleaner.  Even I
understand the way _matlab_helpers and Gcf works now!

    Jeremy> I may need to think about font size scaling separately -
    Jeremy> currently I just define the font point size, which
    Jeremy> probably is not what I should be doing.  I may not have
    Jeremy> time to do this today, but will try to think about it in
    Jeremy> airport lounges ;-)

You probably will.  Font size needs to scale with DPI, otherwise when
you go to a high res output the fonts look really tiny.  I use
something like

    scale = self.dpi.get()/72.0
    self._font.set_size(scale*self._fontsize)

which as I indicated above is not perfect but gets close.

    Jeremy> By the way, I noticed on the users list that people are
    Jeremy> asking for Debian packages. I'm quite happy to do one, but
    Jeremy> would rather wait until things have calmed down - I'll
    Jeremy> target the 4.0 release for a .deb on the Sourceforge site.

I hope you mean 0.4 <wink>.  By 4.0 we'll have already acquired The
MathWorks.

    Jeremy> We'll have to think about how the Debian package
    Jeremy> dependencies are worked out. My inclination is that we
    Jeremy> should require appropriate support for at least one
    Jeremy> backend, and suggest the others. Something like:

Required packages:    python2.3-numeric, python2.3-numeric-ext, fonttools
                      python2.3-gtk | libgd2-dev | libwxpython
Recommended packages: python2.3-gtk, libgd2-dev, libwxpython

Yes, I've been wondering about this but don't know enough about debian
to know how optional packages are handled.  Note that neither gtk, gd,
or wx are required if all you want is PS (or Template!) output.  For
the record, I'll list the dependencies by backend below.  Since I am
not a debian whiz, I'll just list the actual dependencies and leave it
to the experts to sort out the debian packages that provide them

matplotlib

  Numeric

  PS backend
    (nothing extra)

  GTK backend
     GTK2
     pygtk-1.99.16 or later

  GD backend: 
    gd-2.0.15          
    gdmodule-0.42
    fonttools-2.0b1
    TTFQuery-0.2.6

  WX backend:
    wxPython-2.4.2.4

    Jeremy> Debian practice would normally provide separate packages
    Jeremy> matplotlib-doc and matplotlib-examples, so I'll try to
    Jeremy> arrange that.

    Jeremy> However, I don't really want to get into doing this until
    Jeremy> we are ready to make the next release. Debian packaging
    Jeremy> isn't especially hard, but it is rather tedious...

OK, but since we're shooting for release date of around 3 weeks from
now, it might be good to lay the groundwork, figure out how to handle
the optional dependencies, see if we can get gdmodule packed, etc....

Thanks!
John Hunter

I was unable to contact Marco awhile (months) back. I had been foolish
enough to volunteer to package, and he said he'd wait a couple of days and
then do it. After a week or so I wrote to say I wasn't going to get the
time, but my mails kept bouncing.

JV:I think that Marco Presi <zu...@de...> claims to be
JV:working on this.  Maybe you can coordinate with him.
JV:See
JV:
JV:    http://bugs.debian.org/206691


-- 
Charles R. Twardy                    www.csse.monash.edu.au/~ctwardy
Monash University                    sarbayes.org
Computer Sci. & Software Eng.
+61(3) 9905 5823 (w)  5146 (fax)

Hello,

On Tue, Nov 18, 2003 at 10:10:33AM -0000, Jeremy O'Donoghue wrote:
> By the way, I noticed on the users list that people are asking for Debian
> packages. I'm quite happy to do one, but would rather wait until things
> have calmed down - I'll target the 4.0 release for a .deb on the
> Sourceforge site.
> 
> We'll have to think about how the Debian package dependencies are worked
> out. My inclination is that we should require appropriate support for at
> least one backend, and suggest the others. Something like:
> 
> Required packages:    python2.3-numeric, python2.3-numeric-ext, fonttools
>                       python2.3-gtk | libgd2-dev | libwxpython
> Recommended packages: python2.3-gtk, libgd2-dev, libwxpython
> 
> This would allow a Debian user to install matplotlib for only one backend
> (e.g. gd2 only for a webserver without X), but recommend packages to
> support other backends.
I think that Marco Presi <zu...@de...> claims to be
working on this.  Maybe you can coordinate with him.
See

    http://bugs.debian.org/206691

for details.

> I can probably put simple packages for TTFQuery
> and gdmodule , which could be 'suggested'.
At http://seehuhn.de/debian/ you can find a python-ttfquery
package, which I produced for my own personal use.  If
anything else in the Debian archive would use it, I probably
could upload it to the archive.

Best regards,
Jochen
-- 
http://seehuhn.de/

John Hunter said:
>
[snip]
>
> Jeremy - what this means for you is some more changes.  Sorry to
> present you with an ever changing target.  I've been working pretty
> hard of late clearing up a lot of lingering issues.  Hopefully, we'll
> stabilize soon....

I'm not concerned by moving targets - the changes to date have been
sensible both in improving functionality and rationalising the backend
design.

Will try to commit appropriate changes today before I go off on a busines=
s
trip (back Friday, won't have CVS access before then, although I will tak=
e
a snapshot with me before I leave)

> Not sure this is perfect yet, but it seems to be a step in the right
> direction, and the relative sizes of the fonts to the figure appear to
> be better now -- previously too large in some backends, eg, GD.  There
> is still a discrepancy between relative font sizes between the
> backends (eg, GTK versus PS) which may have to do with the font dpi
> issue (75 versus 100 dpi fonts under X11) but am not sure.  In any
> case, I think the CVS changes are step in the right direction

I may need to think about font size scaling separately - currently I just
define the font point size, which probably is not what I should be doing.
I may not have time to do this today, but will try to think about it in
airport lounges ;-)

By the way, I noticed on the users list that people are asking for Debian
packages. I'm quite happy to do one, but would rather wait until things
have calmed down - I'll target the 4.0 release for a .deb on the
Sourceforge site.

We'll have to think about how the Debian package dependencies are worked
out. My inclination is that we should require appropriate support for at
least one backend, and suggest the others. Something like:

Required packages:    python2.3-numeric, python2.3-numeric-ext, fonttools
                      python2.3-gtk | libgd2-dev | libwxpython
Recommended packages: python2.3-gtk, libgd2-dev, libwxpython

This would allow a Debian user to install matplotlib for only one backend
(e.g. gd2 only for a webserver without X), but recommend packages to
support other backends. I can probably put simple packages for TTFQuery
and gdmodule , which could be 'suggested'.

Debian practice would normally provide separate packages matplotlib-doc
and matplotlib-examples, so I'll try to arrange that.

However, I don't really want to get into doing this until we are ready to
make the next release. Debian packaging isn't especially hard, but it is
rather tedious...

Regards

Jeremy

I've just checked in an update to backend_wx.

This has fixes in the fillable shape classes to support the new
fillColor API.

John, I have thought carefully about your suggestion that
NavigationToolbarWx could be exported, and take only a figure in its
constructor, and I've removed the FigureControlWx stuff, and refactored
FigureWx and NavigationToolbarWx so that the toolbar can be used much as
in your GTK example. I think there is a great benefit in making
matplotlib as similar to use as possible with all backends - from both
the user experience perspective and the API.

Therefore, I have also tried to make the behaviour of the mousewheel
more similar to backend_gtk: backend_wx now performs a 'scroll' action
on whichever button the mouse is currently over.

I discovered what I believe to be a wxPython bug in button event
handling: for some reason, the mouseover does not work until at least
one button has been pressed (as for the menu!). I will look into
work-arounds, as this really is not satisfactory.

I have started to put code into place to support saving to bitmaps. This
doesn't work yet (unless you like your bitmaps in black on a black
background), but I thought it better to try to get a working backend_wx
into CVS for the changes you have made. Most of the 'known' bugs are
either fixed, or I have isolated the problem to peculiarities in
wxPython, so I'm focussing on getting some new functionality into place.
Printing first, then I'll look at using double-buffered drawing as
you've suggested.

Any backend_wx users: I'd love any good suggestions on ways around the
couple of wxPython problems I'm having.

Regards

jeremy

In the process of rationalizing the way figure size and dpi is handled
between the various backends, I had to make a number of changes to the
matplotlib backend.  This will pave the way for an rc file in which
the user can set the dpi, figsize, font, etc.. properties for each
backend.  But it required some changes to the Gcf and FigureManager
setup.  It actually simplifies writing a new backend, but will require
some relatively painless changes to wx (GD, GTK, PS, and Template are
already updated).

In a nutshell, the proliferation of defaultDPI and defaultFigSize
throughout several parts of the code and among the various backends is
now gone.  The only place where the defaults are set is in matlab.py
in the figure and savefig command.  This now makes it possible to
control the figsize and dpi from the matlab interface (which before
could only be done with the OO API.  

An unfortunate side effect is that the default appearance of figures
may now be different since I have changed the defaults (different
backends used to set their own defaults, so there was no standard).
Now I use a default fig size of 8,6 (from matlab) and dpi of 72.

Jeremy - what this means for you is some more changes.  Sorry to
present you with an ever changing target.  I've been working pretty
hard of late clearing up a lot of lingering issues.  Hopefully, we'll
stabilize soon....

- Changes to the matlab helpers API

  * _matlab_helpers.GcfBase is renamed by Gcf.  Backends no longer
    need to derive from this class.  Instead, they provide a factory
    function new_figure_manager(num, figsize, dpi).  The destroy
    method of the GcfDerived from the backends is moved to the derived
    FigureManager.  You'll want to connect the window destroy to the
    GCf.destroy method, which will forward the call to the
    FigureManager.

  * FigureManagerBase moved to backend_bases -- seemed like a better
    place for it.

  * Gcf.get_all_figwins renamed to Gcf.get_all_fig_managers

  * No default dpi or figsize arguments in the backends.

  * You'll need to change the backends.__init__ for wx to reflect the
    new API.

It was rather easy to port the existing backends and I don't think
you'll have much trouble with WX.  Note there is a SCREENSIZE
parameter in the backend_gtk and backend_gd which is a constant that
determines how many pixels there are per inch on the screen.  I use
this to convert from dpi (in which I assume a dpi of 72 == 1 inch) to
screen units.  In my tests where I created figures with a dpi of 72,
this resulted in accurate measures of figure sizes (holding a ruler up
to the screen).

Not sure this is perfect yet, but it seems to be a step in the right
direction, and the relative sizes of the fonts to the figure appear to
be better now -- previously too large in some backends, eg, GD.  There
is still a discrepancy between relative font sizes between the
backends (eg, GTK versus PS) which may have to do with the font dpi
issue (75 versus 100 dpi fonts under X11) but am not sure.  In any
case, I think the CVS changes are step in the right direction

Let me know if this is clear ....

JDH

I just committed several changes to CVS.  Most notably, I 
changed the way edge versus face draws are done at the backend level,
as discussed earlier.

For the Renderer methods draw_arc, draw_rectangle and draw_polygon,
the signature is 

  gc, faceColor, ....

rather than 

  gc, fill, ....

faceColor is any legal matplotlib format string.  To convert this to
an RGB, call backend_bases.arg_to_rgb.  See GD, PS and GTK backends
for several approaches to handling edge and face calls.  These (and
other minor) changes more than double the speed of pcolor in the GTK
backend and significantly reduce the size of pcolor PS output.

Other comments pertinent to the WX backend

  - backend writers should no longer need to define figure text.
    Everything is handled by Figure base class

  - artist clipOn is now a protected attribute _clipOn.  Use
    set_clip_on to change it

I've pretty much fixed all the known frontend CVS bugs (scatter bug,
legend bug) and finished the ports of GD, PS and GTK backends to the
new API.  Let me know if you find anything misbehaving.

John Hunter

I have incorporated log transforms into the new axes API and committed
them to CVS.  There are some minor issues to hammer out, eg, ticksizes
in log transforms (which was also a problem before), but its 97.5%
working.

wx generated a nice looking log plot with log_demo.py with no changes
(cool!) but one bug was revealed

hunter:~/python/projects/matplotlib/examples> python log_demo.py -dWX
Traceback (most recent call last):
  File "/hunter/jdhunter/python/projects/matplotlib/matplotlib/backends/backend_wx.py", line 634, in _onSize
    self.bbox.set_bounds(0, 0, w, h)
NameError: global name 'w' is not defined

Cheers!
John Hunter

John Hunter wrote:

> Secondly, I am considering making a minor backend change for drawing
> 2D solids (arcs, rectangles, polygons) in the Renderer.  Rather than
> calling the functions twice, once for edge and once for face, I would
> like to define them like

> Comments?

Only one comment from me: make sure to leave a way for non-convex 
polygons.  It should be possible to draw, for example, a 5 pointed star 
in which the fill shouldn't extend outside the edges.

John Hunter said:
>
> The GTK and wx backends have the same problem with pixel rounding on
> pcolor.  I just cured it with GTK and I bet you can do the same for
> wx.  The trick is to floor the positions and ceil the scales.  This
> will make it much more likely that the left edge of one rectangle will
> align with the right edge of another.  Eg, for the GTK backend
>
[code snipped]

I'm sure you're right. I'll try it tomorrow.

> Secondly, I am considering making a minor backend change for drawing
> 2D solids (arcs, rectangles, polygons) in the Renderer.  Rather than
> calling the functions twice, once for edge and once for face, I would
> like to define them like
>
>    def draw_rectangle(self, gcEdge, x, y, width, height, gcFace=3DNone)=
:
>
> that is, the gcFace takes the place of fill.  If None, don't fill,
> otherwise fill with the gc in gcFace.
>
> This will avoid 2 function calls per patch (once on the patch.py end
> and once in the backend forwarding it to the underlying renderer, and
> will enable backends, eg, postscript, to take advantage of a native
> fill commands.  For PS, this will at least halve the size of pcolor
> output files, which are currently obscenely large.

This seems very sensible. The changes required in backend_wx will be
minimal, and wx has a native fill (well, a brush...), so I can take
advantage of this. Halving the size of PS output is very worthwhile, and
it'll probably double the speed of pcolor on wx.

Regards

Jeremy

I just checked in to CVS a substantial refactoring of the matplotlib
axes classed, with some smaller changes to artist.Artists and their
descendants.  This won't result in any changes to the
matplotlib.matlab interface, and only minor changes to the API for
embedding matplotlib in applications (eg, a one line change to the
embedding_gtk.py example).

But it will make it easier to support, develop and maintain the
library internally.  For example, the legend command works better now,
producing a better layout, and the tick and label placement works
better.

Pretty much everything is working with known examples *except*

 1) log scaling
 2) GD backend

and these two will come along in a day or two.

So please exercise caution before checking out CVS; if you do check it
out, let me know about any bugs you find (it usually takes a while for
the mirrors to sync)

See axes.py for a summary of changes.

Thanks!
John Hunter