1. Understood. Time permitting, I'd be willing to help out with Linux support once you get to that point. I think this type of project might be especially interesting for Raspberry Pis, now that they have full OpenGL 2.1 support being implemented.
2. That makes sense, and It's probably not worth the hassle at this stage to play around with alternate interpreters. I'm just curious because the JIT compiled interpreters like Pyjion, Pyston and of course PyPy are very interesting from a performance standpoint. Sorry, that's a bit off-topic! 3. Some caching makes a lot of sense. It's a pain that the nice lru_cache module is not in Python 2.7, but perhaps a custom module can be included in pyglet/extlibs if it's beneficial. On Tuesday, December 27, 2016 at 10:54:49 PM UTC+9, Serdar Yegulalp wrote: > > 1. Right now this is a Windows-only project. I'm mostly just cobbling > together by hand a standalone version of the interpreter with a > bootstrapper I wrote in Cython. I also have some scripts that "bake" > .pyc-only copies of Pyglet and the app in question into a .zip file. (I > also do some import-time magic so that any .pyc file that has a matching > .pyd file gets the latter substituted in for it, since you can't package > .pyd files in a .zip.) > > 2. In theory you could package PyPy with this, although the size of the > interpreter is daunting -- it's like 50MB -- and I wanted something that > was small and efficient. I don't think swapping PyPy for CPython would be > all that difficult, though, since in theory they are drop-in replacements. > > 3. The performance improvements mostly amount to compiling to Cython, > decorating variables as needed, and replacing the OpenGL calls with their > native C equivalents. But I've seen a couple of other things that can be > done in pure Python. Some functions can be decorated with @lru_cache to > reduce the number of method calls made to them -- for instance, get_texture > for Texture(AbstractImage) at pyglet.image.__init__. > > pyglet.font.base has some other improvements in this vein. (The text > handling part of Pyglet seems to be very unoptimzed in terms of how many > calls are made.) > > The bad news is that I made these changes in a very ad-hoc, not at all > systematic way, so it's tough to reconcile them with the codebase. What I'd > like to do is wait for the next point release, and then backport them > properly so everyone can use them. > > On Tuesday, December 27, 2016 at 4:18:33 AM UTC-5, Benjamin Moran wrote: >> >> Hey Serdar, >> >> That sounds like a pretty cool project. I have a few questions if you >> don't mind sharing: >> 1. How are you packaging the standalone interpreter, and is there any >> chance for Linux and Mac support? >> 2. Secondly, what are the chances for a PyPy version? (I've recently >> become interested in PyPy again now that they're working on 3.5 support). >> >> I'm also very interested in your pyd versions of the Sprite and draw >> modules (Cython I guess, from the pyd extention?). I've been looking over >> the VertexDomain classes recently (due to some work with creating an >> OrderedDomain), and thinking that there might be some small performance >> tweaks that could be done. I'm curious on what you've done, if anything >> besides the Cython type stuff. >> >> -Ben >> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
