Brett Johnson wrote:
>
> So far, the voting has been 2-1 in favor of the context independent
> glX variety:
> The following folks have participated previously, but haven't
> yet responded with a vote.
>
> Bernd Kreimeier
I'm a bit hesitant to replace engineering with (my) voting.
My gut reasoning is this: we expect app coders to call glGetString
first with GL_EXTENSIONS before actually obtaining a proc address.
glGetString is clearly context dependend. "Context" for me means
a black box around the entire processing chain - OpenGL implementation,
GLX/DRI protocol, underlying hardware driver, OS/WM participation.
If any single component in this chain fails to support a given
mechanism (core or extension), the context can't offer it,
which is indicated by calling glGetString.
With the sole exception of extensions to the GLX protocol itself,
a glGetString dependend GetProcAddress should be subject to the
same restrictions as glGetString. Extensions to GLX that are
context independend would require a glxGetProcAddress that can
be called w/o a current context, extensions to GLX that are context
dependend would require a glxGetProcAddress that takes an explicit
context handle (or operates on the current context). Requiring
calling context dependend glGetString before calling a context
independend glxGetProcAddress?
Maybe we should not try to squeeze all 3 cases (context
dependend GL, context dependend GLX, context independend GLX)
through one mechanism?
If glGetProcAddress is context independend, but glGetString is,
then implied or explicit dependency of glGetProcAddress on
glGetString seems wrong to me. My vote is against introducing
a single, context-independend solution - based on gut feeling,
not engineering. I am just being conserative: adding a
context independend solution in a later revision of the ABI
is certainly possible, taking it back is an entirely different
proposition.
b.
