I expect the following extensions will be widely supported in the future on Linux (since they are available on many IHV's Windoze platforms):
EXT_paletted_texture
EXT_shared_texture_palette
EXT_point_parameters
and these (which were also on Thomas' list)
EXT_stencil_wrap
EXT_texture_env_add
EXT_compiled_vertex_array
> -----Original Message-----
> From: Jon Leech [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 4:05 PM
> To: [EMAIL PROTECTED]
> Subject: [oglbase-discuss] Lists of GL extensions for different
> implementations (was Re: 2nd draft: GL_EXT_get_proc_address spec)
>
>
> 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).
> 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.
Also, it looks like we can construct a reasonable
context-independent function using some of the dispatching techniques
people have been proposing. So I'm coming to agree that we should do
this to make life easier for ISVs, though we should still note that a
program portable to Windows will probably treat these as
context-dependent.
Jon Leech
SGI
