Thomas Roell wrote:
|
| > As a practical matter, some applications already take the address of
| > OpenGL functions (in order to avoid some DSO calling overhead, or to
| > pass them to commands like gluTessCallback). If there are cases in
| > which such actions are performed in libraries, the libraries might
| > well break if we decide that the function addresses are
| > context-specific. The same concerns would apply to extension
| > functions as well as core functions.
|
| Could you come up with a example where this presents a real world
| problem ? (mostly asked out of curiousity)
Here's an example of the sort of problem I had in mind. Suppose
someone wants to write a rendering utilities library for game
development. Among other things, this library will have the ability
to draw multitextured triangles. For simplicity we can even assume
that the library routine for drawing multitextured triangles knows
that it will never be invoked unless the current context supports the
multitexturing extension.
The library is intended for use by many applications, so it can know
nothing about any per-context data structures that a particular
application might have. Therefore, when it needs to specify a texture
coordinate, it must do a GetProcAddress on glMultiTexCoord2fARB (or
whatever); it can't just fetch it from some global variable that
contains per-context function pointers.
Calling GetProcAddress is relatively expensive if done often, so the
library will want to cache the return value in a local static pointer.
If GetProcAddress returns different pointers for the same function in
different rendering contexts, the library will fail (by using the
wrong cached function pointer) when the current rendering context
changes between calls to the library.
It's possible to get around this, of course, by redesigning the
library so that it keeps a per-context cache of pointers and checks
the current context each time it's called; or by requiring the
application to notify the library each time the current rendering
context changes. The former is slow, and the latter seems error-prone
to me. (Especially if there's another utility library that might
change the current context! How does it know who to notify?).
This seems to me like a case where OpenGL implementors can expend just
a tiny bit more effort, and make library and application developers
lives *much* easier. (And increase the reliability of applications at
the same time.) I'm with John Dennis on this; I think there are many
OpenGL developers who are likely to be caught unawares if extension
function pointers vary from context to context.
Allen
