[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Pygame's future beyond 1.8



On, Mon Aug 21, 2006, Alex Holkner wrote:

[...]
 
> In the more general case, the small amount of Python wrapper that exists 
> on every Pygame-ctypes function will indeed make it perform slower than 
> its Pygame counterpart.  I would argue that if this small performance 
> penalty is significant for a particular project, then that project is 
> not really suited to be implemented in Python.

If a small penalty of e.g. 0.5ms in a function exists and this function
is called 50 times in your project code you'll have a total penalty of
2.5 ms already. Now let's assume, this function is (or must be) called
periodically...
If the author now mourns about that, are you going to tell him, that
his projects is not suited to be implemented in Python?

Saying things like that basically means, that you do not understand the
pitfalls of software dependencies and how to deal with them.
 
> I am with Richard in planning for Pygame-ctypes becoming the trunk and 
> future development on Pygame stopping at 1.8.x.  Your expertise in 
> Pygame would be invaluable in implementing the required optimisations in 
> Pygame-ctypes, and I would not like to see the community forked.

Why do all people think, that forks are bad? In my opinion this fork
would bring greater benefits to the pygame community. Both versions
can be developed for their very own needs and tweaks. The C version is
definitely suitable for environments with limited resources and
performance (e.g. embedded, older systems, etc.) while the ctype
overhead is not.

The ctype version however allows a fast integration of new features and
possbily less debugging/testing and thus will become from a certain
point of time the more feature-rich one (depending on the development
team around it of course).

Both however can still share ideas, possibly code and anything else, so
I do not see any harms here, but instead a great benefit. This however
can only be, if a transparent, highly responsive development process
exists for both versions.

Regards
Marcus

Attachment: pgpKYWdMRgr3u.pgp
Description: PGP signature