Jamie Bullock wrote: > On Mon, 2008-03-03 at 09:49 -0800, Christopher Barker wrote:
>>> Feel free to amend as appropriate. >> Can I remove the "design flaw" comment? ;-) > > 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", though I suppose we could all it a "limitation", rather than a flaw. But the point it good, separating out the Hit-Test drawing and Main drawing makes sense. >> Why are the images black and white? That's a bit odd. > > Hm.. they're greyscale not b&w. well, yes, if you want to get technical... > 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! > 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. > 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. > - 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. I don't know if there is any hit to making a GC from a DC -- as opposed to having FloatCanvas pass a GC around instead. Of course, there is always the option of going to Kiva, or another Agg-based back-end -- Agg is supposed to be pretty fast. > Braun software (http://sourceforge.net/projects/braun), I have recently > added the option of using anti-aliased lines. Using them increases load > by ~30%. Anti-aliasing is enabled by default, but setting a flag in a > config file turns it off it your computer can't cope. Can you turn anti-aliasing off with GC? If so, do you get the performance benefit? This is also key to the hit-testing code. The way it's written now, it won't work right with anti-aliased drawing -- it expects an object to be drawn entirely in one color. > - 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. > 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... > self._Draw = eval(self.__draw_ + BackEnd) I'd probably do it without "eval", though... Good ideas here! -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
