I wasn't sure if the slowdown was - GTK/Pygtk - The transforms (or other things we do with cairo that may be inefficient) - Cairo in general (or some combination of them).
To try and rule out the first one of these I tried drawing onto an opengl surface using pyglet http://bitbucket.org/stuaxo/shoebot-pyglet/ It seems a little faster, but not significantly (this is subjective as I've only tested one bot so far) If you want to test your bot you can check it out, change size to 600,600 as it doesn't respect size. (only tested with sbot). My next step is to try and convert some bots to pure cairo and see if they run faster, I'd say it seems like your on the right track with making the transforms and matrices quicker though. If it turns out to be cairo then hopefully I can push some bugs in their direction. ----- Original Message ---- From: "architetto francesco fantoni <hva - hermanitos verdes architetti>" <[email protected]> To: [email protected] Sent: Monday, May 11, 2009 8:46:37 PM Subject: Re: [shoebot-devel] why Shoebot can be slow, and a possible way out Ricardo, I think you're absolutely right thinking that 2geom is perfect for bezier handling, as you said it would add all sort of possibility for boolean operations and mathematics on paths, and that would be really great (and it seems rather powerful judging from inkscape). What do you think about text and images? can be managed with lib2geom as well, or we should have an alternative matrix handling for their transformations? I seriously doubt i could manage numpy well enough, i just scratched the surface of it as i needed an array handling routine for the Image code of shoebot and for video frames handling in sbopencv library, but I will try to have a look at 2geom and numpy when I have the time, in order to be able to possibly help when you decide to try the first implementation of a new "next generation" shoebot ;) ciao, francesco Il giorno dom, 10/05/2009 alle 22.34 +0100, ricardo lafuente ha scritto: > architetto francesco fantoni <hva - hermanitos verdes architetti> wrote: > > 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... > > > > True, it could definitely have some helper docs around. But since it's a > rather low-level lib, maybe that's not their priority. The examples are > pretty neat and run on Cairo -- try the python ones, they're practically > self-documenting. There's also something on 2geom on the Inkscape wiki > that briefly shows how it works (writing this off-line, try googling). > > Something like Numpy would go better than Cairo, no doubt. I do remember > being pretty baffled by the complexity of the numpy concepts and quickly > got lost. But hey, you did work with it once, do you think it's doable? > (though i totally understand you won't want to place your eyes on an > affine matrix ever again :o) > > On the other hand, 2geom have their own matrix implementation, and it's > already up and running on the Python bindings. Right now, they're just > missing bezier paths and other less simple primitives (like ellipses). > I'm personally very impressed by the whole of 2geom, especially after > playing with the existing python bindings on an ipython session. Not to > mention that Inkscape, which fundamentally relies on 2geom, regularly > contributes with patches. > > Pardon my excitement, but i really think it's the missing piece of the > whole puzzle. Having a lib to take care of the abstract object data > (beziers, points, etc.) would fit everything together: Bot reads the > user scripts, 2geom objects are created, and finally passed to the > canvas, which will then call the appropriate commands on the back-end of > choice. And it would do away with our current mess regarding transforms > (a mess that works nonetheless, i'd emphasise :) > > So yes, maybe it's not the kind of effort a hacker would fancy, but i > was hopeful i'd find someone who might be able to lend a hand. > > > > 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 > > > > > > > _______________________________________________ > 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 _______________________________________________ Shoebot-devel mailing list [email protected] http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
