On Sat, Aug 15, 2009 at 4:55 AM, Bruce Smith<[email protected]> wrote: > It seems to me that the most difficult immediate issue for the future of > pyglet is what to do about the divergence between the 1.1-maintenance branch > (off of which all releases have been made) vs. the trunk (sometimes called > the 1.2dev branch). The incompatibility between them can confuse new users > and new developers, and leads to more work and possible confusion for all > maintainers. Examples of the confusion: what to check out, which branch(es) > to fix bugs in, and what to do with code in the experimental subdirectory > which only works with the maintenance branch.
I'll do my best to provide a quick summary of where I think things are at. Bear in mind that it's been several months since I worked on these changes, and I haven't checked my facts. The 1.2dev branch includes several new features and several unrelated large refactors of existing features. The scope grew as development went on, which is why for a while most bug fixing continued in trunk without being backported to 1.1-maintenance (which started when I realised how big 1.2 was getting). I have no summary listing of which bugs have been fixed in trunk but not maintenance; refer to the SVN logs and the tracker for specific commits. I'm fairly sure there are no issues fixed in maintenance that have not also been fixed in trunk. Most changes to trunk were first prototyped in the experimental/ directory (of trunk). There are some notes (.txt files) in there that may help in understanding the design or limitations; however these notes should not be read as documentation for the trunk implementation. The major features/changes are: Audio refactor: - Audio decoding and playback occur in separate threads to the main thread; this is to avoid buffer underruns at low framerates and to avoid having the application developer manually tune the ideal buffer size and poll interval. - PulseAudio replaces ALSA as the Linux audio backend - Decoding, synchronisation, output and the public interface are more loosely coupled and interchangeable, with better code reuse between platforms. - Audio/video synchronisation is redesigned, giving better synchronisation and a simpler implementation - Multithreading in Python turns out to be extremely flakey, especially on Windows, where frequent process and even operating system crashes were experienced. I'm not confident that all issues were resolved -- besides the Vista crashes, Python's multithreaded lock implementation is not stable and KeyboardInterrupt signals are not delivered consistently. Interpreter shutdown with daemon threads is not clean. - While A/V sync was greatly improved, synchronisation between multiple audio players was lost. - In general, the media module needs far more testing and development for it to replace the existing 1.1 implementation; or reverted. Video resolution switching - Mostly complete as far as possible given platform limitations (Linux support in particular is limited). - See the new "canvas" module for documentation Window/input/GL refactor - Related to the new canvas module, this reduces coupling between these modules, in preparation for allowing pyglet to interoperate with other GUI toolkits in various ways (embedding in both directions). - OpenGL 3.0 is supported - This refactor is considered complete, however there are probably device configuration issues lingering Tablet and joystick support - Complete as far as scoped for this version. Tested only with the limited number of tablets and joysticks I have on hand. - Also, Apple Remote controls are supported (on OS X). - See the new "input" module for documentation Platform library refactor - Shared platform library constants, function prototypes and types moved to the new "libs" module in order to decrease coupling with "window" module. - Stable, but further refactoring is probably possible from other modules I don't believe the new public APIs have been documented in the Programming Guide, however the module and function-level documentation is fairly fleshed out. I would rate the stability of trunk at somewhere approaching an alpha release for device and platform testing. For what it's worth, my latest PyWeek entry used pyglet 1.2dev internally and no issues were reported (the game had a fairly involved audio component, too). As for advice on future development, I have a few notes which you are free to take or ignore at your pleasure: - The process for creating distributable Windows and OS X packages is extremely time-consuming and error-prone (it is documented in doc/internal). I would suggest dropping these distributions for just the tar.gz/zip packages for developers to drop into their projects. However the download counts for the installation packages are much higher than the source/egg packages. - Speaking of egg packages, these should also be dropped in future; download counts are low and setuptools/easy_install is extremely fragile, leading to broken installations that are difficult to repair if you don't know where to look. - It may be possible to release just some of the new 1.2 features incrementally, rather than all of them at once. However the refactoring of libs and canvas may make this difficult. - I would be tempted to put audio/video in the "too hard" basket, and create a C library with light Python bindings for this functionality (much like AVbin does for media decoding). - A Py3K conversion would be quite a lot of work. Regards Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
