In your message of 17 September 1999 you write:
> 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)
> As I said, although I prefer the static offset implementation, I'll
> honor the consensus if it goes the other way. But I think it's pretty
> important to preserve the ``one function address works everywhere''
> semantic in either case.
Thanx for pointing out a few approaches here. It's very clear that one
can implement device specific dispatching without requireing to expose
context dependant pointers by GetProcAddress().
So let's quickly summarize the issues and open questions:
1. GetString(EXTENSIONS) is needed to query the availabilty of a
certain extension. The value returned is dependant upon the current
context.
2. A non-NULL return value for GetProcAddress() does not indicate the
presence of an extension. It might return a dummy routine that
simply is a noop.
3. It is possible to come up with a internal libGL dispatch mechansim
(which does not have to be exposed at the user API level) which can
deal with per device function/extension handling. Hence
GetProcAddress() does not need to return a pointer on a per context
basis.
4. The existing wglGetProcAddress() however returns a pointer on a per
context basis. Is this important to take into account or not ?
What it boils down to is really what semantics we want at the
application level. My vote is still for going along with the same
semantics as wglGetProcAddress().
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
