Hi Santiago,, without going into to your remarks in detail, I want to give these general observations on the matter: there are two main issues here a) programming style and graphics access and b) graphics technologies and accelaration.
Even Pygame if allows one to do "pixel pushing", I prefer to write programs in an object oriented fashion with Pygame as well and encapsulate drawing in scenes, actor and widget objects. If you do that right, it will as fast as other approaches. When I looked at pyglet, I was at first impressed by it's API because it already provides many of these abstractions for you, at least if you're concerned mainly with animated image sprites. But when it comes to simple drawing primitives like boxes, lines, simple shapes and so on, you'll have to dig into OpenGL, and I find OpenGL one of the most confusing APIs I have ever encountered. And when you ask for help on writing traditional OpenGL with pyglet; you'll usually get an answer like "nobody uses this anymore, learn to use shaders!". Also, many of the nice auxiliary libraries Pygame provides are missing in pyglet and there seems to be no current development. The problem with shaders and libraries (like Kivy) that rely on OpenGL ES 2.0 is that there are still millions of devices that do not support ES properly, like for example Atom netbooks with integrated Intel graphic chips. My three year old EeePC will run a Pygame-based game happily at good framerates but does not support many OpenGL-based games and applications. On the other hand, I am currently checking out the Pygame subset for Android on my Odys Loox tablet (1.2 Ghz single core) and while it runs without problems, my moderately complex test programs, which run with >100 fps on the EeePC, run at around 15-17 fps on the tablet. While I think there's room for improvement, after all pgs4 is still new, using OpenGL seems to be the way to go on Android. I still have to try out Kivy for Android and see how it performs... Chris