Me too I thought that the main bottleneck is in the transforms, I have scripts with images, and text and clipping paths that can run very fast, while simple scripts with lots of transformations are much slower.
I don't know much about lib2geom, i compiled it and had a look at the examples, but i was scared by the total lack of documentation. How about matrix handling using something like numpy? I don't know if it could be done, nor if it could be faster than cairo or not... Il giorno dom, 10/05/2009 alle 18.03 +0100, ricardo lafuente ha scritto: > hey all, > > i was reading through data.py and was reminded of Stu's profiling > results with gtk_main_iteration. > > I believe our main problem is transforms; for each path that a user > creates, Shoebot has to find its centerpoint to determine the transform. > The only way right now is using Cairo, since we have no other lib to > deal with this, AFAIK. This really sucks, using Cairo for such a simple > operation. > > not only that, we have to do a lot of matrix parsing and re-generating > because there is no native Python lib for handling vector shapes, > matrices and data. Our implementation is a bit hackish -- nevertheless, > what we have works and looks great (and supports both Cairo's corner > transform mode as well as Nodebox's center mode), but the footprint of > all these operations begins to show when we use stacked transforms. > > again, our solution would be a library to handle the Path, Matrix, and > all the primitive object types, which we could then use as a replacement > for most of the stuff in data.py. I've looked around a lot and couldn't > find anything similar in Python, but there's still hope -- lib2geom, the > C++ lib that powers Inkscape's path operations, already has some > bare-bones Python bindings. > > i've talked to them on their Jabber channel and learned a bit how i > could help (njh is a great and patient guy :) -- it's mostly an effort > of reading the already existing bindings and writing the same for the > remaining ones. I've sent a patch already for binding a couple of > objects but there's still some work to be done. > > the advantage of this would be, well, awesome: lib2geom supports boolean > operations between paths; for comparison, Nodebox's bezier library is > able to do that, albeit resulting in paths made out of only straight > lines, no curves. And well, if Inkscape uses it as a back-end, we can be > sure it will be a good bet. > > i will be going on trying to add to their binding effort, but my almost > non-existent knowledge of C++ makes it tough on me; if there's anyone > willing to lend a hand to this, well, it would be really really great to > have a Python way to deal with beziers and related stuff, all this > besides how useful it would be for Shoebot. > > if anyone's up for a sprint of sorts to work on this, it would be tops :-) > > :r > > _______________________________________________ > Shoebot-devel mailing list > [email protected] > http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net _______________________________________________ Shoebot-devel mailing list [email protected] http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
