> I'm not even sure *that* will work. To invoke a Sub PMC from C, you > need to pass in an Interp as well as the PMC. Unless you know both > of those at compile time, I'm not sure how to make the callback > mechanism work. > > ... although I just had an evil idea regarding memcpy and a hash table.
Hi chromatic - as you know, I took over the Perl OpenGL project over a year ago - you had mentioned that I might consider doing a port to Parrot; Geoffrey had suggested the same. I've also been wanting to rework POGL's architecture to make it more object-oriented for server- side use. While OpenGL itself does not use callbacks, it is assumed to be single- threaded (there's a "current" context state). As such, GLUT was designed to assume single-threaded uses - which is why it's callbacks do not have user data. It has been suggested that one might "fix" Parrot's NCI to support generic callbacks. There's a fundamental flaw in going down this path: the fix would essentially make any Parrot module using this "generic" callback method single-threaded - which would make it unusable on most modern language bindings - thereby invalidating the point of using Parrot in the first place. The better solution would be to make the underlying C libs (like GLUT) thread-safe by extending their callback interfaces. You can't fix the GLUT callback issue without addressing OpenGL's "current" context interface. Since I was already planning to make POGL object-oriented, I had intended to do a callback wrapper for GLUT anyway. In my mind, this is the right way to address this problem. If no one has any objections (and I'm not stepping on any toes), I'd like to drive this project - just so that we don't have duplication of effort. Otherwise, I'm open to other suggestions. cheers - grafman
