On Tue, 2008-03-04 at 09:16 -0800, Christopher Barker wrote: > > OK, I just removed it, but don't forget *you* added that note, when I > > did the SmoothLines how-to, I just copied and pasted it across! Do you > > want the 'design flaw' bit taken out of the SL how-to also? > > That was supposed ber a joke about my "hurt feelings",
Ooops.. *blush* - here's me - "mr. serious". > > Do you mean that the demo would be > > clearer if I used colour? > > prettier, if not clearer -- but it looks like the window decorations and > everything are greyscale too -- are you working with a greyscale system? > It's not a big deal -- any docs on that site are better than none, no > need to get picky! The window decorators are like that because I use the Ubuntu studio theme: http://ubuntustudio.org/screenshots > > It's a difficult call. I think the advantage of doing it this way is > > that you can add extra functionality to FC that takes advantage of the > > extra advantages of GC and path-based drawing without having to worry > > about having a consistent interface for everything. > > well, except a consistent interface is important. 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. > > There are things you can do with GC that simply can't be done with DC > > Exactly, so there is a real advantage to going -- all-GC. Among other > things, we could let GC do the scaling and shifting to pixel coords -- > though I'm not sure it would really be much faster than the numpy-based way. 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. > > - GC _does_ incur a performance hit, and it would be nice to have the > > option of using DC in performance critical situations. > > 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. BTW, What's a 'strong path'? > 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? 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. > Can you turn anti-aliasing off with GC? If so, do you get the > performance benefit? I'll investigate that. > > - If we work on supporting DC and GC, it will force us to provide an > > architecture that supports multiple backends, and therefore make it > > easier to add additional backends (SVG) in the future. (... or at least > > that's the theory... ;-) > > I suppose so, but I'm a bit reluctant to really commit to that route -- > different back-ends have different capabilities -- it's a mess! If we > really want to commit to that route, I'd say go with an existing > abstraction layer -- Kiva or Cairo, for instance. I'm starting to think that GC is the way to go, the " one-- and preferably only one --obvious way to do it" ;-) BTW, I think that GC actually uses Cairo already on Linux. > > Actually, the more I think about it, the more I think that this should > > be an option set in DrawObject. This could give per-instance backend > > selection, which would be quite powerful. > > Yes, though it would only support back-ends that can draw to the same > thing -- either a DC, or maybe a wxImage or wxBitmap (though DC is > better, as it could support printing, etc) > > > The _Draw() method could be > > assigned by __init__: > > 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) > > self._Draw = eval(self.__draw_ + BackEnd) > > I'd probably do it without "eval", though... Anything specifically wrong with eval in this context? How would you do it - using a dict (as above)? Still learning! Jamie -- www.postlude.co.uk _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
