Michael I Gold wrote:
>
> At 01:59 PM 9/9/99 -0600, Thomas Roell wrote:
>
> >> Also note that the returned pointer is only valid when the current
> >> context is the same as the context to which the GL was connected when
> >> the pointer was obtained.
> >
> >What is the rationale for this constraint ?
>
> Consider the Windows model, which may or may not apply here. Not all
> Visuals are supported by the same DLL, some are from the ICD and others are
> from opengl32.dll (e.g. rendering to bitmap, printer, or if someone
> explicitly wants to use the generic software renderer). If two
> implementations support the same extension, they each have a function with
> the same name in their respective DLL's. It would be bad to call a.dll's
> entry point when bound to b.dll. Not sure if an analogous scenario can
> occur in Linux (multimon perhaps) but its a good idea to plan ahead.
>
> >Would this imply what for every context that is created a seperate
> >pointer had to be queried ?
>
> Technically, the same ptr should work for any compatible context, where I'd
> define compatible as sharing the same Visual.
I'm still not sure I see the reason for all this.
If the address of an extension function depends on the context then that
implies, for example, that
&glPolygonOffsetEXT != glGetProcAddressEXT("glPolygonOffsetEXT")
for some context(s).
I think that's pretty weird. I've worked on an OpenGL application which
deals with several simultaneous GL contexts. Extension handling is
complicated enough without having to worry about context-dependant
extension function pointers.
It seems to me that just as glClear() is able to jump into the proper
context-dependant subroutine, so should glPolygonOffsetEXT() or any
other extension function.
Is it the case that wglGetProcAddress on Windows returns different
function addresses for different contexts?
-Brian
