----- Original Message -----
From: Thomas Roell <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 20, 1999 7:00 AM
Subject: Re: [oglbase-discuss] OK, back to Re: 2nd
draft:GL_EXT_get_proc_address spec
> In your message of 19 September 1999 you write:
>
> > I can see a valid, useful role for context/driver specific procs -- but
more
> > as a route to reduce the call overhead, by-pass error or state checking,
> > and/or expose some of the functionality the display-lists are using
> > internally (c.f. previous post's historical reference to IM_ macros for
the
> > IRIS 2000-3000 series) However, I believe this role isn't clearly
defined or
> > understood in such a way as to specified to the ARB in any multivendor
sense
> > at this point.
>
> The goal of GetProcAddress() is not to change semantics of OpenGL function
> call. It's not meant to retrieve short-cutversions of OpenGL functions.
> All that it's mean for is to retrieve function pointers to extension
> functions as well as core API functions to allow applications to
> access extensions and features without referencing the functions
> directly. This guarantees maximum portability.
We're in violent agreement here. Absolutely.
> Fast-track pointers als
> "IM_" or "#undef SUN_OGL_NO_VERTEX_MACROS" (Sun's version) are
> implementation specific and do quite the opposite of guaranteeing
portability.
given that IHV hardware is now implementing larger and larger pieces of the
OpenGL state machine, and that drivers have to conform to some ABI standard
(be it ICD or Linux Base or Mac or ???) it begs the question, is there a
core set of reasonable, common, and somewhat portable shortcut extensions
that COULD be defined. This is however clearly beyond the scope of the
currect glGetProc discussion. So I'll leave this topic to be brought up in
some other forum later.
John M. Zulauf
Santa Barbara, CA
805 968 3225
