Hi everyone, I think glX, gl, and glu each need their own GetProcAddress functions. Here are my thoughs. If I want to provide an OGL API for manipulating contexts, visuals, or any new window system interaction I need window system GLX info from glXGetProcAddress. A context independent function seems an obvious choice. If I want to provide an OGL API for new window system independent functionality I need glGetProcAddress. Providing only a glXGetProcAddress skews non-windowing based OGL. Regarding glGetProcAddress, I like context dependent pointers for performance but in the interest of long term robustness I think context independent functions are required. When multimonitor has been discussed I take it as multiscreen which an application can manage. As Xinerama rolls in (http://www.xfree86.org/snapshots/3.9.16/RELNOTES2.html#8) does the driver writer really want to worry about this as well as these types of future enhancements? I support context independent functions returned by glGetProcAddress for robustness so whatever future upper layers evolve my driver handles relatively transparent. If vertex interface performance is a problem, why not use vertex arrays or a GL_SUN_vertex ;-) varient (this extension is not the SUN_OGL_NO_VERTEX_MACROS short cut). Aside from Xinerama, is there an idea how MT-saftey will be achieved? Context independent gl functions allow a dispatch manager to introduce indirections to handle MT-gl, that is, calling the same function from two different threads. Wouldn't context dependent functions force the driver to have to deal with this as well? It appears static dispatch tables for core and dynamic for new extensions have the consensus and I agree. I take it everyone is in agreement gluGetProcAddress which I also support. Thanks for your time. Ron p.s. At Sun we have the concept of a Graphics Pipeline Interface (GPI) to avoid confusion with true OGL API discussions. Up to now I've noticed "dispatching API" referenced and it would be nice to give this imposed layer (that is currently not being defined) a name for discussion sake and to avoid any confusion with the true OGL API.
