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. 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.

- Thomas
-- 
             Thomas Roell   /\         An imperfect plan executed violently
             Xi Graphics   /  \/\ _     is far superior to a perfect plan. 
         [EMAIL PROTECTED]   /   /  \ \     
                         / Oelch! \ \             George Patton

Reply via email to