Menu
▾
▴
matplotlib-devel
|
From: Jeremy O'D. <je...@o-...> - 2003-12-02 16:14:27
|
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 |
|
From: John H. <jdh...@ac...> - 2003-12-02 16:33:52
|
>>>>> "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
|
|
From: Jeremy O'D. <je...@o-...> - 2003-12-02 17:59:49
Attachments:
backend_wx.py
|
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 |
|
From: John H. <jdh...@ac...> - 2003-12-02 18:30:36
|
>>>>> "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
|
|
From: Jeremy O'D. <je...@o-...> - 2003-12-02 20:30:04
|
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 |
|
From: Jeremy O'D. <je...@o-...> - 2003-12-03 00:01:32
|
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 |
|
From: Jeremy O'D. <je...@o-...> - 2003-12-02 23:35:58
|
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 |
|
From: John H. <jdh...@ac...> - 2003-12-02 23:44:16
|
>>>>> "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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X