Jamie Bullock wrote: > What I meant was, you don't need to worry about having to engineer one > interface for multiple backends, each of which has different > functionality.
right -- this is key really -- if we really want to support multiple back-ends (and I'm not sure we do), the "right" way to do it is with an abstraction layer for drawing -- the weaker way to do it is to require each DrawObject to have a draw method for each back-end supported. For a few types of DrawObjects, it doesn't make much difference, but without the abstraction layer, making new draw objects is harder -- I guess it all depends on ho many back-ends you want to support -- two, not a big deal -- ten, and I'd really want the abstraction layer! For the moment, I think the easiest way to go is to have GC be the API for a future hypothetical abstraction layer -- then we don't have to worry about it! GC is already an abstraction layer -- it used different back-end APIs on the different platforms. > My hunch is that it would depend on the backend used by the GC itself. > I've noticed *massive* differences between platforms. For example on my > MacBook Pro the performance can be around 60% worse under OS X than > under the Linux when using GC. I suspect that one of them takes > advantage of hardware accelerated graphics and the other doesn't. Could be, but I'd expect it to be the other way around, on OS-X, GC uses CoreGraphics -- that should be hardware supported -- GTK used Cairo, which may not be. What version of wxPython is this? >> yup. -- I wonder how much of a performance hit, really. I know if you >> use a GCDC for drawing a large polygon, for instance, the hit is >> substantial - but it's less so if you optimize the GC use -- strong >> paths, rather than regenerating them each time, etc. > > Sounds like we need to do some benchmarking. I might start a > benchmarking page on the wiki. That would be great. > BTW, What's a 'strong path'? A typo -- I meant "storing paths". Re-creating a path takes time (I think -- benchmarking is in order). As every time you draw a polygon you need the same path, storing it, rather than re-creating it on each draw, could help a lot. The trick here is projections and scaling -- the current system stores only the World coordinates, then computes the projection and scaling at each draw. That's nice, as it allows a lot of flexibility in the projecting, scaling, and shifting of coords, and the DrawObject itself does not need to know anything about it. If we store the path, what coordinates is it in? If we do the scaling and shifting with GC itself, then that can work, but projections can not necessarily be defined in terms of affine transforms, which is all GCs can do -- I wonder if there is a way to apply an arbitrary transform to a path? It doesn't look like it from the docs. That makes it look like if you use a non-affine projection, you'd need to store projected (but not scaled and shifted) coordinates. I was hoping to avoid that, but it may not be possible -- benchmarking is in order. >> Of course, there is always the option of going to Kiva, or another >> Agg-based back-end -- Agg is supposed to be pretty fast. > > Hmm.. just took a look at Agg, and it looks pretty nifty. Does anyone > know how well it works with wx? It's used in Kiva, and Matplotlib, and ??? -- it plays fine with wx if you draw to the buffer with Agg, then just move the buffer into a wx.Bitmap, which can be done efficiently with newer versions of wx. > For me FloatCanvas's 'plug n play' > wxPython support is a big selling point, although I appreciate that FC > was originally designed to be semi-independent from wx. Actually, it wasn't -- it was designed to be usable without knowledge of wx drawing methods, but it's been wx-centered from the beginning. One of the key issues with using Kiva, or Agg, or ??, is that it introduces a compiled dependency. I suppose numpy already does that, but numpy is very well supported, with binaries available, and it compiles easily on lots of platforms -- I don't think Kiva meets those standards yet. I also don't know if Kiva is complete enough for us -- and adding to a Agg back-end gets beyond what I can do. > I'm starting to think that GC is the way to go, the " one-- and > preferably only one --obvious way to do it" ;-) I'm thinking that too. > BTW, I think that GC actually uses Cairo already on Linux. Yup, but I don't know if that buys you all the other Cairo back-ends though -- I don't think so. >> or better, yet, by a property, so you could change it... > > You mean so you could do something like: > > my_canvas.backend = "DC" # or whatever > canvas.draw() > > Where in the class def we have: > > def set_backend(self, backend): > ... > # self.draw_funcs is a dictionary of _Draw objects > self._Draw = self.draw_funcs[backend] > ... > > backend = property(get_backend, set_backend) something like that, yes. > Anything specifically wrong with eval in this context? It just makes me uncomfortable, and is not necessary for this kind of thing -- you can usually use apply(), or set attributed directly (see Jehiah's reply) -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 [EMAIL PROTECTED] _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
