Nitro wrote: > Next I'll try to do the same thing with a different library (written in > c++, interfaces opengl/direct3d directly) and compare its performance to > that of fc2. I have the feeling I can still have many nodes visible and it > will be blazing fast.
Probably, yes. In fact, we're building our new app here not with FC or FC2, but with something new, built on OpenGL. We started out evaluating FC, FC2, Chaco/Kiva, plus some testing with raw DCs and GCs. (note that I didn't make the primary recommendation, nor am I writing most of the code) The end result was that you can render thousands of points, lines, bitmaps, etc. with OpenGL blazingly fast, and none of the other methods touch that. However: 1) OpenGL is pretty darn low-level. We've had to write WAY too much code to do simple stuff like drawing a filled polygon, and it has essentially not text support at all. 2) A lot of OpenGL, or at least GLU, requires lots of individual calls to the library, often one call per vertex: for polygon tesselation, for instance. Doing this in Python is a performance killer. We're looking at using Cython to write C version of some of this stuff. 3) You don't get a full range of transforms. As it looks from your note, the full-featured arbitrary transforms are costing a lot in FC2 -- We found the same thing in Chaco. We've approached that by essentially having two copies of the data around -- the raw data in "world coordinates", and a copy transformed into a linear, orthogonal coordinate system. We then let GL do the panning and scaling to pixel coordinates for us. This works pretty well, as you only need to do the transforms when new data is added or changed. You get nice fast zooming and panning. However it doesn't allow the arbitrary nested transforms that FC2 has. 4) There are also issues with stuff that you don't want to scale: like text and objects that stay the same size as you zoom. You have to change that size on each render -- you get some help 'cause you can often use the same data that's already been passed to GL, though, but you do end up making a lot of calls in a python loop on each render. 5) how stuff is rendered is somewhat left up to the video card, some make prettier results than others. All that being said, if any of you want to see the code, I'd be glad to send it along. At the moment, we're using it for a very custon map-based data manipulation interface, but it the long run, we hope it will be general purpose and we can release it as an open-source project. -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://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
