This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Future of OpenGL package (Earnie, please read this)


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@cygwin.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]