From: John H. <jdh...@ac...> - 2004-03-19 13:01:12
|
>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes: Hi Jeremy! Jeremy> Hi John, I'm (slowly) getting around to doing all of the Jeremy> things needed to bring backend_wx up to date (as far as Jeremy> possible). backend_wxagg will arrive, but I'm trying to Jeremy> get some other things into backend_wx first, specifically: Good idea to port the stuff to backend_wx first .... Jeremy> - Support for images (which is turning out to be trickier Jeremy> than I thought) - Support for the object picker (which Jeremy> should be easy) - Support Mathtext Jeremy> The problem of Mathtext support is a superset of the image Jeremy> support problem. Jeremy> The approach which I'm looking at is to use wxImage, which Jeremy> has a fast method for loading data (wxImage.SetData()) - Jeremy> ths expects a C string of length width*height*3 (in format Jeremy> RGBRGBRGB...). Jeremy> Not sure what format im.as_str() returns as I can't find Jeremy> any documentation (the im parameter to Jeremy> RendererWx.draw_image() is an instance of Jeremy> matplotlib.image, I assume), so I'm stuck (or was a couple Jeremy> of nights ago). Thanks for letting me know about the doc problem. I updated the doc string with "The string is a numrows by numcols x 4 (RGBA) unsigned char buffer". The best place to look in the code for guidance is backend_gtk rows, cols, s = im.as_str() X = fromstring(s, UInt8) X.shape = cols, rows, 4 You'll want to lose the alpha channel presumably, unless wx supports it, something like RGB = X[:,:,:3] s = RGB.tostring() # to pass into the wx draw_rgb_from_buffer I can also provide an as RGB method in the image module if you want - see if the above works and if you are happy with the performance. If not, let me know. mathtext, while closely related, is a little more difficult. The image returned by as_str is an MxN array of alpha values (no color information). See backend_gtk again for guidance. In the example from backend_gtk below, rgb is an rgb tuple and pbpix is an MxNx4 RGB array. pbpix[:,:,0]=int(rgb[0]*255) pbpix[:,:,1]=int(rgb[1]*255) pbpix[:,:,2]=int(rgb[2]*255) pbpix[:,:,3]=Xs So each of the color elements in the RGBA array is constant and only the alpha value is varied with the return value of font as_str. If wx has no alpha channel, you'll have to do the blending yourself. If there is get_image_rect, you can get the background image background and manually blend the pixels. This is what I was doing in backend_gtk before Trevor Blackwell showed me how to use the dark, undocumented RGBA from numeric array support in pygtk. [If you just ignore alpha, eg, and just set RGB anywhere alpha>0, it will look like crap; I tried]. But if you can efficiently get the background image into a Numeric array, you can do the blending yourself w/o too much work. Easiest would be if wx supports rgba. Jeremy> As you say, writing wxAgg is really pretty Jeremy> straightforward, and it's on my (ever lengthening) ToDo Jeremy> list... At the moment I don't have anything in a usable Jeremy> state. When you get the image_as_rgb thing working, we could do a wxagg dry run by having backend agg provide image_as_rgb_str. My experience with GTK and image support is that this is surprisingly fast, and has acceptable interactive refresh rates while resizing etc. It shouldn't be the final solution for efficiency sake, but should be trivial to implement and wouldn't require any additional extension code. Basically you just remove the renderer and the GC and forward all the calls in the figure canvas to renderer agg, and then you could use the currently nonexistent agg.image_to_rgb_str to render the image to the wx canvas. Down the road if you want to blit from extension code, you could do class FigureCanvasWxAgg(FigureCanvasWX): def draw(self): """ Draw to the Agg backend and then copy the image to the wx canvas """ agg = self.switch_backends(FigureCanvasAgg) agg.draw() try: import _wxagg except ImportError: w, h, s = agg.renderer.image_as_rgb_str() wx.draw_rgb(s) else: _wxagg.blit(something, agg.something) which would be nice because it would support users who couldn't compile the additional extension code. I should look into doing something similar in GTKAgg :-) JDH |