Am 04.05.2010, 17:08 Uhr, schrieb Christopher Barker <[email protected]>:
> a couple others: > > 2) look at enthought's "traits" package -- it does something similar, > but they have hacked in low-level C code to give it better performance. What really needs optimizing is the algorithm here though, not just the implementation. Internally fc2 creates way too many events and I think they are even relayed from object to object in certain situations. Even if the current implementation can be made 10x faster, it's still way too slow. Sometimes I think the current auto code is too much magic and the user should be required to call canvas.update() manually. Of course this can get ugly, too, especially if you want to split your functionality into small functions and/or use the render-to-surface nodes. Render-to-surfaces nodes need to know when one of their children changed, so they can redraw themselves to a bitmap. Now if you'd use the manual updating scheme, this can get ugly for the user, because he has to figure out when one of the children changed. Now if you consider somebody might write a fc2 library A and you combine it with another library B, then it's not so clear anymore who's responsible for updating which node. Something the OP could try as a workaround is creating the objects once and then saving them. And then reloading instead of recreating. But this won't work for all situations and I am not sure if it will be any faster. -Matthias _______________________________________________ FloatCanvas mailing list [email protected] http://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
