Werner F. Bruhin wrote:
Great to see a new release, will put some time aside to test it with wxPython early next week.
looking forward to your reports.
which versions of wxPython are supported?
I haven't tried the new one, but the last release worked well with wxPython2.6.3, but had some issues with 2.8.* -- I don't think anyone has addressed those yet.
Well, we haven't built any binaries yet. We pushed a source release
fast to try to get it into Feisty. Sorry Chris!
well, I've been chattering on about this for awhile, but haven't contributed anything yet...
> With wx2.8 out now
and this being a major release, we definitely need to rethink wx
builds. We stuck with unicode for 0.87 to avoid confusion. I would
be happy to hear what wx users think/want.
I think it's time to just all unicode, all the way, but I mostly deal with English anyway.
For me the ideal would be not to be depended on a particular release of wxPython - big surprise no
That would be nice.
If I understand it correctly the dependency came in for performance optimization, does 2.8 change something for this.
Perhaps. 2.8 has methods for directly setting the data in wxBitmaps. Before that, you needed to create a wxImage, then convert that to a bitmap.
However, to do that right, you'd need to be able to get the Agg bitmap as a Python buffer object that is in the binary form required by the platform. I think the majors need RGB and/or RGBA, but I'm not totally sure about that (maybe OS-X is ARGB?)
- If yes, I would not see a problem with 0.9 requiring as a minimum 2.8.0.1 but going forward I could use any 2.8.x or newer release.
That would be a good way to go, or have fallback on the older methods for less than 2.8 -- so instead of saying "you need 2.8 to use the wx backend" we can say: "you'll get better performance with wx if you use > 2.8"
- If no, then I guess we have to live with having a "fixed" dependency, e.g. 0.87 is wxPython 2.6.x, 0.90 is wxPython 2.8.x, but it should through at least a warning if one tries to use it with another wxPython release.
Yes, it should. I've also started a patch for the build system that tries harder to make sure that you are building against the same wx that you are running -- that will at least help people built it themselves more easily.
NOTE: I took a look at the wx backend code a while ago, and it looks like even without the new Bitmap handlers in 2.8, it could be faster with straight Python code. Key is that a wxImage can be created from a Python buffer object without copying the data. So if we can expose the Agg buffer as a Python buffer, as RGB, then we should be able to get decent performance with pure python. You'd still need to do the wxBitmapFromImage thing, but the accelerated back-end does that too.
Look for a thread on this list a while back, with my and Ken's name on it.
-Chris
ยทยทยท
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...