On Wed, 2008-03-26 at 16:27 -0700, Bob Free wrote: > Cool - great to hear from you - sorry that it's been a while since I've > posted an update!
Real life can be so darned intrusive .... ;-) > It'd be great to have you participate - you've done quite a lot for POGL. > Regarding your work/ideas on abstracting GLUT - definitely want to leverage > that - I'll let you know as soon as I'm ready to tackle this. Fair enough. > As for automating support for new OpenGL extensions, I wrote a perl script > back when I first started this project that parses glext.h to generate > glext_procs.h - which helps abstract WGL and GLX implementations. > Attempting to fully automate it may be problematic - particularly for APIs > involving pointers. Worth investigating, tho. Definitely. Would you mind sending that over? I can poke and prod at it a bit, see what I can manage. > A related task that I've been contemplating is to support OpenGL extensions > dynamically (like WGL) - so that a binary build can be distributed for a > given distro - rather than having to be built from source. POGL's binary > distros for Windows (PPMs) works on any Windows box with an OpenGL driver > (standard on NT/XP/Vista) - this doesn't work for other platforms. I keep thinking we should just do runtime stub patching everywhere, as with GLee/GLEW/SDL/etc. The nice thing is that this can be done cleanly in Parrot, because setting up a Parrot NCI sub involves doing dlfunc calls anyway [*] -- and Parrot's core handles making the 'dlfunc' op do the right thing on every platform. [*] Unless you manually create a library wrapper in C using Parrot's C API -- which *might* produce very slightly faster code (debateable, in the face of JIT for PIR code), but which seems to be leaving us back in the hellish XS place again. > BTW - since we're talking about doing a better Perl OpenGL implementation - > it has always bugged me that the Perl APIs involving pointers have a "_c" > suffix. I get the "_s" and "_p" suffixes, but my preference would be to get > rid of the "_c" suffix. Oh certainly, those are not only ugly, but won't be mnemonic for all Parrot languages. Since Parrot very deeply has multiple dispatch, we may not even need to have different names at all -- they may just properly dispatch based on arguments. I have no experience with the performance of Parrot's multiple dispatch -- if it proves to be slow, we can revisit the suffices, but definitely choose better ones. Or we can present the evidence to the core Parrot team and ask them to make multiple dispatch faster, which ought to help the performance of several high level languages as a bonus. ;-) -'f
