PyOpenGL Testing on Linux and Win32 Today
Last update on .
Spent most of the afternoon and evening working on PyOpenGL testing today. Whole raft of small bugs fixed. Also did some refactoring of the OpenGL_accelerator support code, still want that to be cleaner. I've also added a top-level flag to PyOpenGL so that you can disable accelerator loading on a per-application basis. Unfortunately, that's going to require re-testing on Linux.
Good news is that on Linux Python 2.6 and Win32 Python 2.5 pretty much everything in the demos and OpenGLContext I've tried works, with the exception of NURBs on Win32 (they appear scrambled, as though there's a packing/indexing issue or the like).
Win32 Python 2.6 Accelerator compiles with Mingw32, but the results can't load due to the inability to find the msvcrt 9.0 dll. It appears I'm going to have to install MS's free compiler on the Vista machine in order to support 2.6 (or spelunk through and figure out why it needs the run-time in the extension modules). Non-accelerated Python 2.6 still works fine.
There were some bugs in the WGL module, which I've worked around for now. Eventually need to look into making the wrapping mechanism understand the difference between void *'s that are arrays and those which are just opaque pointers. WGL is still not particularly well tested, so I wouldn't be surprised if we saw other code-rot issues in there.
Seeing a weird bug from ctypes where a function with a c_void_p return-type is returning long ints instead of void_p's. It just *happens* to match (almost) the legacy behaviour (module long versus regular int), and interact well (save being long) with win32ui, but it's not what was intended.
There was also a bug in the GLUT Win32 wrapper, where the hacky exitfunc value wasn't properly supported. That prevented killing GLUT windows (ouch).At some point I really need an automated test suite, even with just 2 platforms and 2 versions of Python with 2 options (accelerated/unaccelerated) testing all the corners is becoming a multiple-day job. Particularly when you're 3/4 of the way through what you thought was a final test and realize you need to refactor some core piece of code (thus restarting the process) it would be nice to be able to say "yes, computer, go do that again".
Comments are closed.
Pingbacks are closed.
Richard Jones on 07/09/2009 8:28 p.m. #
You might be interested in the test suite set up in pyglet - it attempted to automate a bunch of the testing. First run would have the tester visually check a result and save off an image for any future run to compare against. We actually shipped the generate images for a brief while before we realised that practically every person's computer would generate slightly different output :)
Mike Fletcher on 07/10/2009 11:30 a.m. #
Yeah, mostly I've been thinking about how to deal with the slightly different output issue. I suppose I should do the "what's easy" part first, then think about how to do the hard part :) .