matplotlib-devel Mailing List for matplotlib

>>>>> "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