Significant update to backend_wx

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:

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.

    > 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).

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.

    > 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 all Suspect that this is a GTK 1.2 issue, but
    > 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.

    > John, is it worth activiating the Sourceforge bug tracker
    > 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

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 was
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 to
draw into the bitmap) seems quite different between the two platforms. The
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() and
uncomment DrawBitmap() (they are equivalent) and see if the figure appears
on screen.

Where the printing is concerned, again, you could try uncommenting the
'self.bitmap.SaveFile()' line, which checks whether it is possible to save
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.

    > 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).

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)

    > John, is it worth activiating the Sourceforge bug tracker
    > 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 - especially
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 later.

Regards

Jeremy

backend_wx.py (55.5 KB)