In your message of 9 September 1999 you write:
> On Thu, Sep 09, 1999 at 01:59:49PM -0600, Thomas Roell wrote:
> > I would strongly opt for having the few entry points that the OpenGL
> > 1.1 SI added there, as well as the texturing extensions to OpenGL
> > 1.0. Our experiance with customers who are proting down from other
> > platforms has been that those are considered very core.
>
> Works for me. I don't see glPolygonOffsetEXT in your list, though?
> It's an interesting case because the semantic behavior actually changed
> between the extension and the 1.1 feature. Another area to be very
> careful of in implementation is GLX protocol generation, since
> extensions and core features use different protocol.
That is the very reason why I haven't added it. Basically the list
came from our EV2+, where we added all the extensions to the library
and the X-Server to be backwards compatbile with a OpenGL 1.0
application.
In the case of the texture extensions, the protocol is identical
between the extensions and the 1.2 GLX specification. If I'm mistaken
here, I'd appriciate a comment.
> > Please let's avoid this. It would be intresting to know as to why
> > people are using this approach.
>
> Until an updated OPENGL32.DLL is shipped with Windows, apps cannot
> directly access the 1.2 entry points even if an ICD has them.
So it's really more being forward compatible, than any tricks one can
play to get more performance. In that case I'd strongly opt for doing
exactly the same for LINUX.
> > > 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 ?
> >
> > Would this imply what for every context that is created a seperate
> > pointer had to be queried ?
>
> Mostly the rationale is support for heterogeneous multihead.
> Extensions not in libGL will give back function pointers into the client
> driver. It's unlikely that an implementation of an extension in one
> card's driver would work for a different card. If there's an easy way
> for the app to determine that two contexts both referred to the same
> head, we could relax the constraint to that extent.
Well, for an implementators side, you still have to deal with direct
execution vs. display list compilation. Hence an additional level of
indirection is needed anyway. Wouldn't that take care of different
driver issues behind the scenes ? (yes, it will mean some work in the
library, but be more consitent).
Having complex semantics of similar contexts (think about different
extensions for different screens) makes things messy. If you have to
have a seperate set of pointers for each context you create is a
nightmare for application programmers.
For a heterogeneous multihead scenario the clean way to do this would
be more like this (identical to glXQueryExtensionsString()):
glXGetProcAddressEXT(int screen, const GLubyte *name)
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
