In your message of 9 September 1999 you write:
> 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.
On the other hand, this means that unless you use the same XVisual (or
FBConfig) for two contexts, you still have to have two pointers,
despite the fact that the same function is used internally. Having
semantics like that will lean application developers to use
GetProcAddressEXT() for each function call, as it is confusing what
function is returned when. I strongly opt to have this burden rather
on the driver developer than on the application developer.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
