Christopher Barker wrote: > Michael Droettboom wrote: > >> Christopher Barker wrote: >> > A number of threads on the wxPython list. Here's a couple: > > http://aspn.activestate.com/ASPN/Mail/Message/wxpython-users/3519845 > Thanks. I had seen these threads already -- I was hoping you had some more. > a quote from that: > > "" > An interesting phenomena > I've noticed is that the rendering speed is directly related to the > number of pixels that get pushed - scale the tiger up to 500x500, with > it all visible on screen, and it's slower. Scale it down to 10x10 and > the rendering is lightning fast. Move it off screen so that only a > portion shows, and it's even faster. > """ > > This seems to indicate that clipping is efficient -- hmm. > That doesn't seem at all surprising, unless the time to render increases faster than the number of pixels. That's an interesting question to answer.
It also is different from what I was talking about in the sense of clipping. The effect I see is that when an explicit clipping rectangle is applied (e.g. the axes), speed decreases about 8x. I don't get the same effect using Cairo directly, so that leads me to think there's something in the wx abstraction layer that's causing this. > Here is another one: > > http://lists.wxwidgets.org/pipermail/wxpython-users/2007-August/067098.html > > >> Eventually you do have to draw something >> to the screen, right? >> > > yes. > > >> Is there another way to do that besides going through a DC? It >> doesn't seem possible to create a wx.GraphicsContext >> without providing a DC (at least in Python). >> > > No, I think you've got that right. There is: > > """ > wxGraphicsContext::CreateFromNative > > Creates a wxGraphicsContext from a native context. This native context > must be eg a CGContextRef for Core Graphics, a Graphics pointer for > GDIPlus or a cairo_t pointer for cairo. > """ > > But I doubt we'd want to get into that for MPL. > Yes. But it is not usable from Python. In the "new" docs (which have Python-specific annotations): """ Creates a wx.GraphicsContext from a native context. This native context must be eg a CGContextRef for Core Graphics, a Graphics pointer for GDIPlus or a cairo_t pointer for Cairo. NOTE: For wxPython we still need a way to make this value usable. """ http://wxpython.org/docs/api/wx.GraphicsContext-class.html#CreateFromNative >> In my testing, it seemed >> that clipping of any kind caused a major decrease in speed, not the >> kind of DC being used. >> > > If you can come up with an self-contained example of this, a post tot he > wxPython list may yield results. > It might be worth it just to get to the bottom of this. Like you, I'm not a Wx backend user either, so I haven't been terribly motivated. The change to wx.GraphicsContext was really only made to have something that sorta-kinda-works with the new "everything is a polycurve" refactoring that went into 0.98. But I would just as soon deprecate it in favor of wxAgg. I think the best we'll be able to do performance-wise with wx.GraphicsContext is the same as the Cairo backend (since wx.GraphicsContext is built on top of Cairo on X11, at least), which is already slower than Agg, so there's no compelling reason for the Wx backend to exist, IMHO, *unless* it needs to integrate with other code that draws to a wx.GraphicsContext. (To avoid a flamewar: I didn't say "Cairo is slower than Agg", I said the "Cairo backend is slower than the Agg backend", and the reason for that is somewhat by "cheating". The Agg backend makes a number of optimizations, such as line simplification and marker blitting, that the Cairo backend doesn't do. Perhaps they could be done, but I haven't looked very deeply there. Plus, the agg backend is primarily C++ that we can control and optimize for matplotlib, whereas with Cairo mpl uses the stock pycairo wrappers.) Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
