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
>>>>> "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
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 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
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
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. I have just run through all of the regression tests, and with assert self.Ok() in GraphicsContextWx.__init__() removed, all works correctly on my Debian platform. My suspicion is that the problem is that wxGTK does not like to see calls to Ok() in derived constructors. Please let me know if this fixes the problem on your machine, John, as I now have no problems on the two platform available to me. A few other notes: - Save to TIFF does not work on my Linux box. wxGTK generates a 'not supported' error message. - Text is not anti-aliased on my Linux box. I suspect that this is probably a GTK configuration issue on my box (other GTK 1.2 apps aren't anti-aliased either), but I'd love confirmation. - Performance of double buffering is vastly better on wxGTK than on Win32. The performance under Linux is subjectively very similar to the old GDI-style version, but (as previously noted) much worse under Win32. I am not sure why this should be the case (my Linux box is much lower spec than the Win32 box, as well!) Regards Jeremy
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
>>>>> "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