Hi All,

Arguments *for* context-specific function pointers from glGetProcAddress:
(possibly MacOS specific, but maybe not...)

1)  On the Macintosh, the link library (libGL.so equivalent) manages multiple
graphics devices with independent drivers in a way that is transparent to the
application.  It does this by exporting a wrapper layer that may redirect the
OpenGL commands from one driver to another, or to multiple drivers
simultaneously, depending on the configuration of the screens and the
current location of the application window.  In general, an application
may bypass the overhead of the wrapper layer by accessing the *real* GL
entry points that are stored in the context.

When an app calls glGetProcAddress, what is really returned is a pointer
to a function that is generated at run-time - a wrapper for the real pointer(s)
returned from the driver.  The problem is that two contexts may very well
be attached to two entirely different drivers, making the *real* proc pointer
for one context useless for another.  Or, one context may be attached to a
single driver while the other is attached to multiple drivers, making the
wrapper function itself inappropriate for use with the wrong context.

The only way I can see to code my way around this is to A) ignore the
wrapper function issue and accept the logic overhead of a generic wrapper
AND B) keep track of all calls to glGetProcAddress in the link library
and have the library internally extract all the previously requested function
pointers from each driver whenever a new context is created AND C) go
back and "fix up" all existing contexts with each new call to
glGetProcAddress so a procedure may be used with a context that was
created previously.  What a pain!

It seems to me that any X implementation for Linux that tries to tackle the
multi-screen problem in a generic way (like Conix/Apple did) will run into
similar difficulties, so I think it would be prudent to leave the per-context
pointers in the spec.

2)  Further, one context may support the extension of which the function
pointer is a part and another context may not, making the pointer useless
for the second context.  glGetString may return different extension strings
for different contexts in a multiple-graphics-device environment, so it
follows semantically that glGetAnythingEXT must return context
specific information.


Bob Beretta,
Apple Computer
408-974-1051
[EMAIL PROTECTED]

Reply via email to