In your message of 10 September 1999 you write:
> On Fri, Sep 10, 1999 at 04:19:36PM -0600, Thomas Roell wrote:
> > In your message of 10 September 1999 you write:
> > > Is it really that difficult for the programmer to keep track of which
> > > section of code is in which context? [...]
>
> While we're still hashing this out, I'd like to start constructing
> lists of supported GL/GLX/GLU extensions in Mesa, Xi, Metro Link, SGI,
> etc. implementations. We can put them together in various ways to see
> what subset it makes sense to guarantee that static entry points exist
> for. I've made a first cut at this and updated section 3.6 of
>
> http://reality.sgi.com/opengl/linux/linuxbase.html#3
>
> with lists for current SGI graphics hardware; please pass along
> additions for other graphics hardware or implementations in use now
> (Linux, other Unix, Windows, whatever - just include a label or name for
> the platform and implementation / hardware).
For our next version we will be supporting these extensions (relative
to OpenGL 1.0/1.1):
GL_ARB_multitexture
GL_EXT_abgr
GL_EXT_blend_color
GL_EXT_blend_subtract
GL_EXT_bgra
GL_EXT_compiled_vertex_array
GL_EXT_copy_texture
GL_EXT_draw_range_elements
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_subtexture
GL_EXT_texture
GL_EXT_texture_clamp_to_edge
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_object
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_EXT_import_context
GLX_SGI_swap_control
GLU_EXT_object_space_tess
GLU_EXT_nurbs_tessellator
> > First off it is difficult for an application programmer to deal with
> > any changes they have to make to a Windows/OpenGL version to port it
> > to Linux. Worse, with adding context-dependant function pointer you
> > require them to make structural changes.
>
> The Windows function pointers are already context dependent (or
> technically, dependent on which driver the context is dispatching to, as
> Michael described).
>
> If we want maximum portability between Windows and Linux, then there
> should be a single query functionally equivalent to wglGetProcAddress()
> (no matter whether its prefix is gl, glX, glFF (Funky Function), or
> whatever). I follow the arguments for having {gl,glX,glu} versions that
> each only return entry points in those libraries, but pragmatically I'm
> unconvinced that it buys us much.
I would vote for only having glXGetProcAddressEXT (GL + GLX) and if
needed, gluGetProcAddressEXT.
I would also follow the windows semantics here of not being context
dependant, but driver dependant, which means in our case, that if two
contexts are created for the same X11-Screen (or whatever the
equivalents for the emulated GLX cases are), then the pointer returned
by glXGetProcAddressEXT() should be identical. This takes care of the
multi-context issues, and makes it also easy on the driver side to
have multiple different graphics boards (as they can return different
pointers). If a driver needs to brank to different routines for
different GLXVisuals, it still can do that behind the scenes. If an
application uses multiple screens, then only a little burdon is added.
This seems to be more implementable than a difficult dispatch scheme.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
