In your message of 17 September 1999 you write:
>
>
> Thomas Roell wrote:
>
> > > For the record, here's my super condensed opinion:
> > >
> > > In a single screen, homogeneous driver environment, it makes no difference.
> > >
> > > In a multi screen, heterogeneous environment, glGetString may return different
> > > extension strings for different contexts, therefore glGetAnythingEXT
> > > must return context-specific information. An app must check the extensions
> > > per-context, so it must do *all* its extension specific setup per-context,
>including
> > > obtaining function pointers.
> >
> > I fully agree here with you. The only thing where I'm a little bit
> > hung up is whether core API functions retrieved via
> > glXGetProcAddressEXT() are also context dependant.
>
> You're right. Someone previously noted that glGetProcAddressEXT served two purposes:
> 1) to obtain new extension procedures that are unknown to libGL.so, and 2) to obtain
> core function pointers directly from the driver to bypass a wrapper layer implemented
> by libGL.so. So, we're trying to 1) add functionality, and 2) provide an
>alternative coding
> method for apps to improve performance.
Actually 2) was not a goal at all (maybe a sideeffect). The need for
retrieving a pointer to a core functions comes from the idea that an
application writer might want to make use of a OpenGL 1.2 function,
but wants to make sure that the application still runs linked against
a 1.1 libGL.so. However using GetProcAddress() might result in such
speedups for certain libGL implementations.
> I submit that GL_EXT_get_proc_address is provided to address 1) and that there are
> much better ways to address 2). On the Macintosh, an app can bypass the wrappers and
> access the entire entry point set directly from the driver by including an
>additional header
> that allows the app to dereference the context. For example:
>
> glVertex2f(x, y); /* normal method */
>
> becomes
>
> myContext->disp.vertex2f(myContext->rend, x, y); /* direct method */
>
> This is a much smaller burden on the app than programmatically obtaining each
> required function pointer by name and storing it in local space.
Absolutely correct. SUN is doing the same for their SPARC
implementation. However this is really outside our scope here, and as
agreed upon in some earlier discussion really implementation
dependant. A feature like this should not be used in a binary portable
application.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
