Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Wed, 1 Oct 2003 10:17:16 -0500 (CDT) From: Brian Ford X-X-Sender: ford AT eos To: cygwin AT cygwin DOT com Subject: Re: Future of OpenGL package Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Note-from-DJ: This may be spam Andre Bleau wrote: >Brian Ford wrote: > >>Andre Bleau wrote: >> >>>Brian Ford wrote: >>> > >1.2 and 1.3 defines & prototypes are already there in >/usr/include/w32api/GL/glext.h > Yes, I know. That statement started this thread. They (1.3+) are not available in /usr/include/GL/gl.h which is now found first by gcc 3.3.1. Also. /usr/include/GL/gl.h and /usr/include/w32api/glext.h are not compatible. I think we are in agreement here. >>>>As for the extension loading library, it's a don't care for me. >>>> >>>Then, I guess you never had to work with extensions... >>> >>No, I just don't think it is that hard to write code for it. >> >It's not hard to write new code that uses GL 1.2+ that targets only the >Cygwin and Mingw platforms. What's hard is to port some code for UNIX >that calls GL 1.2+ functions. You have to track each call and modify it >to load the function first when compiled for Cygwin. > Now I understand your statement. Igor's idea looks like a workable one here too, and it would be more transparent. Just my 2c. >>>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 >>> >>Ok, but... >> >>>- Add glut.h to /usr/include/w32api/GL >>> >>That may not fly. As I understand it, the w32api directories are only >>for headers/import libraries for DLLs that ship with MS, or at least >>mingw. >> >Old versions of the w32api package didn't provide any GL headers, so the >OpenGL package was (and still is) creating a symlink from >/usr/include/w32api/GL to /usr/include/GL. Then newer versions of the >w32api package started to include GL headers in /usr/include/w32api/GL. >As the last version of that package is newer than the last version of the >OpenGL package, most people have the w32api headers instead of the >symlink, but if you reinstall the OpenGL package, you will loose those >headers and get the symlink. > Most people have them there, true. But with gcc 3.3.1, they don't get them right now because of the include path precedence. Just clarifying. >So, there is a precedent for a glut.h in /usr/include/w32api/GL, in the >form of a symlink. > There is a precedent to allow this symlink in Cygwin, yes. There isn't a precedent to put glut.h in w32api/GL. But, I'll just shut up now and stop speculating about what Earnie will allow in w32api. >>Is the glut DLL -mno-cygwin safe? Then it might work if glut became >>part of mingw. >> >Yup. The GLUT dll does not depend on Cygwin, so compiling with >-mno-cygwin works. > Great! If glut becomes a mingw package too, then my point above is probably moot. Since I am not a mingw developer, my point above is probably already moot. (I confess to not know anything about mingw packages and distribution.) >>Earnie? >> >Yeah, Earnie, where are you? > I don't want to SPAM, but should we CC the mingw-users list now? >>BTW, I guess you're probably not interested from your previous comments >>on the subject, but an Xfree based glut would be great to have. I got a >>working imake compile once without too much trouble from the Nate Robins >>version. If you're still not interested in putting it in your glut >>package, maybe I'll propose to maintain one for Xfree. >> > >The problem is that an XFree GLUT could only draw using an XFree GL. And >XFree GL does not support hardware acceleration, so it is slower by a >factor 10 to 100 when compared to Windows'GL. That's the main reason why >I don't think an XFree GLUT is worth the trouble. > True, but XFree may eventually have a pass through mechanism like on MacOS (I can hope, can't I? If I ever get time, I might actually impliment it. :-D) And, there are a few weird people that actually want to do indirect remote GLX with glut :). -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- 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/