I'd prefer that the whole thread about the future of pyglet and
related issues remain in this group since the _users_ of pyglet are
the ones that are needed to keep the development of this library.
Also, I think the users should know what is going on with the library.
At least I want to keep track of the changes, even though I'm not
planning on helping the development.
I'd prefer that the whole thread about the future of pyglet and
related issues remain in this group since the _users_ of pyglet are
the ones that are needed to keep the development of this library....
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.
I would rate the stability of trunk at somewhere approaching an alpharelease 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).
- 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.
- A Py3K conversion would be quite a lot of work.
....
It sounds to me as if we should focus our efforts on bringing trunk up to a full release, and put 1.2dev on hold for the immediate future.
....
Cleaning up the issue tracker would be a good first step though, even
going through and giving some of them a status would be useful.
On Sat, Aug 15, 2009 at 4:22 AM, Tristam MacDonald <swift...@gmail.com> wrote:....It sounds to me as if we should focus our efforts on bringing trunk up to a full release, and put 1.2dev on hold for the immediate future.
Alex: thanks very much for your status description, that's just what we need.
Tristam: To clarify a possible misunderstanding: AFAIK, trunk and 1.2dev are the same thing, in the svn repository. That is, the most recent releases have been made from
http://pyglet.googlecode.com/svn/branches/pyglet-1.1-maintenance/
but new features and refactoring intended for "development towards 1.2" (as well as many bugfixes) have been done only in the trunk, i.e. in
http://pyglet.googlecode.com/svn/trunk/
since there is no separate (non-trunk) branch corresponding to 1.2dev. This means that "bring trunk to a full release, but put 1.2dev on hold" is not so simple, since trunk and 1.2dev are two names for the same "branch".
This is incorrect. 1.2dev is trunk, as Bruce described.
The enhancements_1_2 branch was a working branch for some of the new
features and can be disposed of now.
The experimental/ directory has always just been a place to put ideas,
whether slated for eventual release or not.
Alex.