Mail Archives: cygwin/2003/09/30/19:34:41
Igor Pechtchanski wrote:
>On Fri, 26 Sep 2003, Andre Bleau wrote:
>
> > ...
> > Even, with 1.4 headers, you would sill need to jump through hoops to use
> > 1.4 functionality. You will still need to load the functions dynamicaly
> > before using them. You wouldn't be able to simply call the functions as
> > when developing for UNIX.
>
>André,
>
>Cygwin DLL uses the autoload functionality for some of the required
>functions, so that they can simply be called after a test (i.e., something
>like
>
>if (hasSomeFunction())
> callSomeFunction();
>
>Perhaps this could be employed in the OpenGL library layer as well... I
>don't know enough off-hand about the autoloading process, but there is a
>fairly detailed description in winsup/cygwin/how-autoload-works.txt in the
>Cygwin sources. Might be worth investigating...
>
Well, that's exactly what packages like extgl provide: an easier way to
test if some functionality is available, and if it is, to load it and use it.
I was thinking of including extgl in the next major release of the OpenGL
package.
However, porting UNIX program that uses GL 1.2+ functions would still be a
pain, although a somewhat lower pain. Say you have a UNIX program with a
line like this:
glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN);
The Cygwin version would be, if we would use something like extgl:
Option A:
if (hasNewFunctionThatDrawsACompleteKitchenIncludingTheSink)
glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN);
else {
fprintf(stderr, "Sorry, can't draw your kitchen. Please update your GL
drivers and come again.\n");
exit(1);
}
or, Option B:
if (hasNewFunctionThatDrawsACompleteKitchenIncludingTheSink)
glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN);
else
myOwn2000LinesOfCodeFunction(GL_KITCHEN_COLOR_PATTERN);
There are dozens of GL 1.2+ functions now. If you select Option A,
rewriting some program to use them conditionally can be a major task. As
for Option B, it is a task of Herculean proportions.
> > [snip]
> >
> > I think we waited long enough for freeglut and some update of GLUT and GLUI
> > is overdue.
> >
> > So, I propose to make a quick update of the OpenGL package ASAP, while we
> > wait for freeglut. To quick update would:
> >
> > - Remove /usr/include/GL and rely on /usr/include/w32api/GL from the w32api
> > package, that would be set as requesite
> > - Add glut.h to /usr/include/w32api/GL
>
>So you need to coordinate with Earnie on this (as the subject says).
Yup.
> > - Update the GLUT dll to Nate Robin's 3.7.6
> > - Have GLUI and GLUIX libs compiled for gcc 3.3
>
>You will probably also need to release the old libraries as compatibility
>packages for those who still use the pre-gcc-3.3 OpenGL binaries.
So, you suggest that I provide:
libglui.a and libgluix.a for the last version of gcclibglui-gcc3_2.a and
libgluix-gcc3_2.a for gcc 3.2
libglui-gcc2_95.a and libgluix-gcc2_95.a for gcc 2.95
???
None would be bigger than 500k, so the package would still be manageable.
> > - Move the doc to /usr/share/doc
>
>This would be useful.
>
>Just my 2c.
> Igor
After the long silence that followed my last posting to cygwin-apps about
these issues, it's good to receive some feedback. Thanks Igor and Brian.
André Bleau, Cygwin's OpenGL package maintainer.
Please address all questions and problem reports about Cygwin's OpenGL
package to cygwin AT cygwin DOT com .
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -