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.
Probably is a GTK2 thing. Do you have access to a GTK2 machine to
test?
> This sounds worryingly as though you do have the latest
> version (there was no file save dialog code at all until
> this morning).
Yep, same problem with the attached code.
> 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.
I diagnosed why the print code doesn't save a file. It hangs
indefinitely on the call to
gc = self.drawable.new_gc()
> 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.
Tried Blit versus DrawBitmap in both. No help
> 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.
No help, due to the hang on new_gc
Any other ideas?
JDH
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 6:22 pm, John Hunter wrote:
> 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.
Probably is a GTK2 thing. Do you have access to a GTK2 machine to
test?
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 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.