I looked at GLEW and it looks like a nice solution for a lot of people.
I'd love to use it, or something like it. I'd looked at it in the past,
and I just checked on it again today as per your suggestion. I came up with
some issues that are important to me personally that would need attention
before I'd be able to use GLEW instead of the the code I already have:
1) Doesn't support several extensions I've already been using for a long
time. This being the case, I might as well continue with my existing
a) Not an extension per se, but I'd still have to manually
get pointers for functions like glTexImage3D() on Win32
(since they APIs >= GL 1.1, which is all that's guaranteed there..)
I don't see any support for this in GLEW (from what docs I've read)
b) GLX_SGIS_multisample (old SGI-specific multisample extensions,
older revs of IRIX lack support
for the ARB extension)
GL_SUN_read_video_pixels (Sun XVR-4000 multisample readback funcs)
GLX_SUN_video_resize (XVR-4000 video resize)
2) Uses global variables. Implicitly thread-unsafe. Can also be unsafe
in some dynamically loaded libraries. Should use some other method
of extension availability enumeration. See 3) below.
3) I can't see how this system could work properly when opening several
OpenGL windows on a multi-display system where different heads are
driven by different graphics accelerators that support different
extensions or have different extension function pointers.
I know this is not a typical use-case, but I have to deal with this
in my application soon, and I don't want to be fighting
with someone else's library to make this work.
If I'm completely missing something obvious, tell me.
Creating multiple GL windows on multiple X displays (or even Win32
displays) is an issue I'll have to deal with shortly. It'd be great
if GLEW handled this gracefully.
4) Yet another library to have to compile, test, and link against on
each of about 8 platform builds I have to do.
As it stands, I already have to make patched/fixed versions of several
well known libraries like FLTK, Tcl/Tk, and others to fix or workaround
bugs in the officially released versions they provide, particularly
when building on new platforms.
In short, I already have too many library dependencies in my opinion...
5) The included makefiles were probably written on Linux and fail
immediately when used with a standard make utility.
(i.e. not GNU make):
make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen
If you develop code on Linux or MacOS, its easy to fall into using
Makefile constructs that only work with GNU's make....
6) When run with GNU make, it goes and downloads all of the latest
extensions. While cute, this takes a while and might be a rude
surprise if one is compiling on a laptop or something.
(I'm thinking of end-users of VMD that know nothing about OpenGL, but
might want to compile VMD from source....)
At the end, the build failed:
Downloaded: 4,682,041 bytes in 279 files
sed -i -e '7s/\<ATI_/GL_ATI_/' registry/ATI/texture_env_combine3.txt
sed: illegal option -- i
gmake: *** [registry/.dummy] Error 2
6) The problems in 5) are a perfect example of why I don't use libraries
unless I really need them. Most of the free software on the net these
days is written on Linux and hasn't been tested on non-Linux machines.
Since my software has to run on Linux, Solaris, IRIX, AIX, HP-UX,
Tru-64, Windows, and MacOS X, I don't want to have a build fail and
have to be fixing someone else's Makefiles or 'sed' script if I can
Also, special compiler options (i.e. 64-bit versus 32-bit builds)
are typically a stumbling block for most packages that were originally
developed on PC's or other 32-bit only platforms. I build both 32-bit
and 64-bit binaries on IRIX and Solaris, with more platforms coming as
time goes on. I don't know if GLEW has this problem, but its one of
the things I hate having to manually fix when I'm building libraries
like Tcl/Tk that have broken configure/Makefile setups. You might try
building GLEW in both 32-bit and 64-bit mode and see that it compiles
and links right.. :)
Anyway, I'd love to use GLEW or some extension library that does the same
sort of thing. I don't like maintaining my own extension code, but at the
present time it appears to be a necessary evil until something comes along
that addresses the issues I list above and does what my existing code already
does for me.
If GLEW can fix/address the issues above, I could easily see ditching the code
I've already written and start using it instead. Until then, I don't have
much choice really. If you need someone to test your code on many platforms,
I have basically one of each of the major platforms here. You'll need to
fix the non-portable Makefile and 'sed' problems first though.
On Mon, Jan 12, 2004 at 10:11:59PM +0100, Marcelo E. Magallon wrote:
> On Thu, Jan 08, 2004 at 04:17:03PM -0600, John Stone wrote:
> > Is there any chance we'll see updated glext.h/glxext.h/wglext.h
> > headers posted to the OpenGL SDK site any time soon?:
> > http://oss.sgi.com/projects/ogl-sample/sdk.html
> > Specifically, I'd like to see an updated glext.h that includes the
> > new OpenGL 1.5 ARB extensions for the OpenGL shading language. (i.e.
> > glUseProgramObjectARB(), glUniform3fvARB(), ..... and the various
> > GL_ARB_vertex_shader GL_ARB_fragment_shader GL_ARB_shader_objects
> > #defines....)
> I hope it's ok for me to plug this here: take a look at GLEW,
> http://glew.sf.net/, a library that eases the use of OpenGL extensions.
> Disclaimer: I'm one of the authors of that library. It includes
> support for currently available OpenGL extensions, with a couple of
> exceptions (SGI extensions to GLX, IIRC). It's very easy to use, very
> portable, and we have paid attention to portability. It works on
> Windows, Linux, MacOS and IRIX.
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns@xxxxxxxxxxx Phone: 217-244-3349
WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078