Py_buffer underwhelms so far
Written by
on
in
Snaking.
I spent this evening getting the Py_buffer support in PyOpenGL worked through the codebase. Originally I'd converted the numpy handler to use Py_buffer when in non-accelerated mode, but in the end it didn't provide much of anything other than the occasional "duh" moment where a piece of code assumed that you could treat an output numpy buffer in numpy or ctypes array style (i.e. index it, take lengths, you know, useful stuff), and some crashes with memory-mapped files.
The buffer handler is currently just registered for bytearray and memoryview objects, and it seems to work for those in simple tests, but so far I'm not all that enthused about the results. While the buffer API is working, the type-specific plugins for each of the major types that support it are all providing more useful information. For instance, the "ERROR_ON_COPY" flag requires that each type be able to say, before getting the buffer, whether a copy is required to produce the buffer.
In working through the changes, I've actually made PyOpenGL's plugins slightly more robust, it will still, by default, attempt to load numpy to use it for array output, but it doesn't automatically load all format handlers on startup, so you could, in theory, suppress loading numpy even if it is installed. All in all, however, I think I'll leave this work and the next time I get some PyOpenGL time I'll work on ES/EGL support instead.
Pingbacks
Pingbacks are closed.
Comments
Comments are closed.