Re: [matplotlib-devel] Significant update to backend_wx

[Jeremy O'D. <je...@o-...>]

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