As far as I understand OpenGL, it's got one current context per thread, and libGL does all sorts of evil things with threads and thread-local storage to make it all work transparently. An object-oriented OpenGL interface seems like the right way to go, though, for all sorts of other reasons.
Arcady On Wed, Mar 26, 2008 at 12:31 PM, Grafman <[EMAIL PROTECTED]> wrote: > > 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 > >
