Am 04.12.2009, 08:25 Uhr, schrieb Nitro <[email protected]>: > FC2 has some performance problems with many nodes on the canvas. I > started improving that yesterday. For testing I use a canvas with 1400 > nodes on it (about 50 visible). Moving a group around or panning is very > very snappy. It gets slower if more nodes are visible, I have yet to see > what I can do about that.
I've checked in some code which should make fc2 somewhat faster. If present on the system, fc2 will now use http://pypi.python.org/pypi/Rtree/ . However, it seems to be buggy and does not work in 1 or 2 demos. It speeds up culling/picking if there are many nodes on the canvas. Optionally you can also call fc.enableSpeedMode() now before doing anything else. In this case you'll have to trigger the re-rendering yourself though. This avoids all the performance overhead of the "dirty" flag handling and event sending. All in all I wasn't able to make it run as fast as I wanted it to. If you do a profile run with cProfile you can easily see the bottlenecks. It's especially slow with many objects being visible. The GC functions itself don't even take up a lot of time (around 10-20%), it's mostly in the functions which setup things like rendering order, transforms, etc. There also seems to be lots and lots of calling overhead from python itself. At this point I don't know how to optimize it much further. With lots of work one could maybe get a factor of 2-4x out of it. For me own purposes this might still be too slow. 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. -Matthias P.S.: Feel free to performance improve fc2 more. _______________________________________________ FloatCanvas mailing list [email protected] http://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
