Add new buffer protocol support to Pygame 1.9.2

#25 Merged
Deleted repository
default (5435417840f7)
  1. Lenard Lindstrom

Thought I would do this formally, since this involves a lot of changes. It was tested with Python versions 2.5, 2.7, 3.2, and 3.3 on Linux Mint 14 Nadia (32 bit version) and Python 3.3 on Windows XP.

Warning: This branch includes additions to the Pygame C api. Local Pygame builds need to be complete rebuilt after pulling these changes.

Comments (8)

  1. René Dudfield
    • looks nicely tested :)
    • C code could use some inline comment documentation.
    • Is get_view API being dropped? Should mention that if the case.
    • should any of the APIs be private?
  2. René Dudfield
    • Are there any installed files removed by this? Like .so/.dll or .py? If so, we can add them to the list of files to remove at install time. So when people update their install it should still work.
    • I think OSX, clang, weird-endian, and 64bit platforms need testing.
  3. Lenard Lindstrom author
    • (Is get_view API being dropped? Should mention that if the case.) Surface.get_view has never been a part of an official Pygame release. It was introduced in 1.9.2a0 when I believed Python's memoryview object type would actually become useful, that is, get_view would at some future point return a memoryview instead of a custom Pygame object. When it became obvious that memoryview was unsuitable, I decided to solve two problems at once, make the View type more general, and use it as a replacement for the existing BufferProxy. So rather than deprecating the get_buffer API, introduced in Pygame 1.8, it is expanded to also export a surface as an array.
    • (should any of the APIs be private?) The new BufferProxy type is stable enough to become a standard Pygame object. The newbuffer module is still a work in progress. My intension is to make it stand-alone. It is adequate, as it is, for Pygame unit testing. But it is not ready for general release.
    • (Are there any installed files removed by this?) Nothing from Pygame 1.9.1 that I can think of. I suppose _numericsurfarray can go, as only NumPy is available now. But this is unrelated to new buffer support. The view extension module disappears, but then this was never part of an official Pygame release.
    • (I think OSX, clang, weird-endian, and 64bit platforms need testing.) Absolutely. Though I can run 64bit gnu/linux, I do not use it in practice. And I have no way to test a big-endian build.
  4. René Dudfield

    Nice :)

    I think we should commit this to the main branch? That will make it slightly easier to test (since we have those buildbots setup to build from there).

    Would be awesome if we can get some more comments in pygame C code generally... we're a bit lacking there. We don't really have a systematic approach to C comments so far... like a normal way to document functions or data structures.

    Jason, can we set up a time you can make your OSX machine available? Probably some weekend is best for me.

  5. Lenard Lindstrom author

    Just about done here. So far I have removed ambiguous switch statement default clauses, made some spelling corrections, and made a slight improvement to new buffer format handling. I am currently restoring Surface.get_view(). Surface.get_buffer() goes back to just returning a raw bytes view, while get_view() only returns structured array views. Both will share the extended BufferProxy.

    I can document BufferProxy and add more C comments once this branch is merged back to the main branch.