On Wed, 2008-03-26 at 09:31 -0700, Grafman wrote:
He lives! Just kidding, I know you've had actual paid work going
on. :-)
> 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.
FWIW, I still think that's a good path. My time comes in short, widely
spaced bursts -- it's much better to have someone who can be doing more
steady work running the whole thing. I can then jump in here and there
with patches, whenever I am able.
> I've also been wanting to
> rework POGL's architecture to make it more object-oriented for server-
> side use.
I was hoping that OpenGL 3 would be out about 6 months ago and give us a
clear ARB-approved set of classes to build on, but the ARB has become a
black hole of late (and there are persistent rumors that certain very
large companies have been actively blockading release of the spec).
Thus, probably best to work from the best info we have about their
intended design, and expect to be making some changes when OpenGL 3 is
finally specced.
> While OpenGL itself does not use callbacks, it is assumed to be single-
> threaded (there's a "current" context state).
Well, at least that there is only one thread doing rendering; there may
freely be other threads doing non-rendering tasks.
> 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.
There is only one Parrot async scheduler thread, correct? Wouldn't it
be safe to direct all implicitely single-threaded bindings through the
async scheduler thread? Or has it been too long since I read that PDD?
> 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.
I had finally been convinced by others this was the right thing to do
anyway, since the generic callback mechanism was not likely coming any
time soon. I just hadn't had the tuits yet. :-)
> 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.
Please do. Like I said, I'd rather be patching than in charge. FWIW, I
had written some proof of concept code that might help you get up to
speed. I've also got some code to hide the nastiness needed to handle
toolkits (like GLUT) that want to preparse the command line arguments at
init time and hide toolkit-specific args from the calling program. Let
me know if you want a copy of any of this.
Also, I've been thinking about the problem of staying up to date and
complete with the current OpenGL version and all extensions. I did some
investigating on CPAN and found a couple different ways to handle
auto-wrapping C headers, including one I found very interesting that
deeply separated the concepts of parsing the C headers from generating
the wrapper code.
The basic idea is that a dedicated C header parser converts from all the
crazy nasty hacks found in normal C headers to canonicalized data about
structures, enums, defines, and prototypes. It then spits out some
intermediate files that are both vastly easier to parse and easy for
humans to modify. (This latter point is key, as I'll point out in a
minute.) The auto-wrapper then reads one or more intermediate files and
produces wrappers from it.
My immediate thought when I saw this was to make sure that re-running
the C header parser would not mess with human-made changes. This could
probably be most easily done by saying that the header parser generates
one set of files ('gl*.auto' for instance), and humans edit another set
('gl*.delta' or what have you) containing only overrides. These
overrides could mark something to be removed, or wrapped with a slightly
different set of parameters, or to do a typemapping, or even to add new
convenience APIs. We might even support overrides expressed as Perl
code, that do things like convert any single function that expects a
pointer to a big array of floats into multiple versions, one taking a
handle to a raw memory buffer, one taking a PMC number array, another a
HLL list, etc.
In any case, having this sort of two-pass wrapping with a nice powerful
hook in the middle to add human intelligence seems like a good way to
get 90+% of the core and extension APIs handled cleanly. Any remainders
can still be hand coded, but that keeps the OpenGL maintainer (or in
fact the maintainers of any similarly large, constantly updating APIs
like GLib/GTK+/Gnome or QT/KDE) from having to do mountains of pointless
busywork.
Consider it a PNT (Parrot NCI Toolkit). :-)
-'f
