Re: Future of OpenGL package (Earnie, please read this)
I think we waited long enough for freeglut and some update of GLUT and GLUI is overdue. FreeGLUT has certainly gained momentum in recent months, but I sould say that GLUT will still be needed for a while. I recently suggested to the FreeGLUT list that GL/freeglut.h should be used, rather than colliding with GL/glut.h --- as a migration path so that GLUT and FreeGLUT could be packaged side by side without conflicts or confusion. If you have an opinion on that I suggest you chime ni. Just to let you know, I am acting as caretaker for GLUI at the moment: http://www.nigels.com/glt/glui/ I am thinking of doing a 2.3 release later this year, nothing major, mainly fixing minor irritations. If there are any GLUI forks out there, it would be nice to merge them back... (I also have a bunch of contributed patches which I'll need to evaluate for inclusion) Nigel -- 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/
Re: Future of OpenGL package
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/
Re: Future of OpenGL package (Earnie, please read this)
Andre Bleau wrote: Igor Pechtchanski wrote: 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. 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: I think you missed the point here. On UNIX, a test is already required to check the OpenGL version or if the extension is supported; assuming the application programmer did the right thing. So, no new tests are required. And, Igor's suggested method is completely dynamic and transparent, just like UNIX. extgl requires code modifications, all be it simple ones. What am I missing? - 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. No. I think that would only be necessary if they were DLLs. I think Igor was confused. Notice that he said pre-gcc-3.3 OpenGL binaries not pre-gcc-3.3 compilers. 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. I hope my feedback is still useful, not frustrating. I have a bad and unintentional habit of being too argumentative here or something. Thanks. -- 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/
Re: Future of OpenGL package
Brian Ford 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. A lot of the functionallity I need is just the defines. Ex: GL_MIRRORED_REPEAT_ARB Here, I don't need to load any extensions. When I do need to load extensions, having the defines for the proper prototypes around would be nice. 1.2 and 1.3 defines prototypes are already there in /usr/include/w32api/GL/glext.h ... 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. ... 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 version sof 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. So, there is a precedent for a glut.h in /usr/include/w32api/GL, in the form of a symlink. 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. Earnie? Yeah, Earnie, where are you? ... 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 your 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. André Bleau, Cygwin's OpenGL package maintainer. Please address all questions and problem reports about Cygwin's OpenGL package to [EMAIL PROTECTED] . -- 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/
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 [EMAIL PROTECTED] .
--
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/
Re: Future of OpenGL package (Earnie, please read this)
On Fri, 26 Sep 2003, Andre Bleau wrote: Brian Ford wrote: Andre Bleau wrote: ... Are there any plans to update Cygwin's OpenGL headers to include 1.3 or 1.4 support? Be it via using the w32api Mesa ones, or by other means. Let that be clear: headers alone will not provide access to OpenGL 1.2+ functionnality. You will still have to program the loading of OpenGL extensions, if they are available from the graphic card driver. Maybe something like extgl (http://www.levp.de/3d/index.htmlhttp://www.levp.de/3d/index.html) could be packaged for Cygwin to make that easier. Sure, I know headers don't magically create functionality. They just allow access to that which already exists. But, most vendors these days (ATI Nvidia) provide 1.3 or 1.4 functionality. It would be nice to use it without jumping through hoops. 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... [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). - 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. - Move the doc to /usr/share/doc This would be useful. Just my 2c. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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/
Re: Future of OpenGL package (Earnie, please read this)
Andre Bleau wrote: Brian Ford wrote: No; if /usr/include/GL does not exist anymore, gcc will look in /usr/include/w32api/GL for #include GL/gl.h directives. Ahh..., ok. I didn't realize that. Makes sense, though. I was just being dense. 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. A lot of the functionallity I need is just the defines. Ex: GL_MIRRORED_REPEAT_ARB Here, I don't need to load any extensions. When I do need to load extensions, having the defines for the proper prototypes around would be nice. BTW, what version does Microsoft ship with XP? It is still 1.1. I guess that M$ is so involved now with DirectX that they will never update the OpenGL dll. Ugh, ok. 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. I think we waited long enough for freeglut and some update of GLUT and GLUI is overdue. Ok. 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. Is the glut DLL -mno-cygwin safe? Then it might work if glut became part of mingw. Earnie? - Update the GLUT dll to Nate Robin's 3.7.6 - Have GLUI and GLUIX libs compiled for gcc 3.3 - Move the doc to /usr/share/doc Great! 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 your still not interested in putting it in your glut package, maybe I'll propose to maintain one for Xfree. Cheers. -- 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/
Re: Future of OpenGL package
Andre Bleau wrote: Brian Ford wrote: I am glad that the ambiguity in gcc include search paths has been resolved. However, the OpenGL includes in w32api/GL are from Mesa, and are thus more complete and up-to-date. Well, I hope that Earnie Boyd, maintainer for the w32api package, will join this discussion. I hope so too. What are the long term plans, if any, for reconciling these two implementations? It seems silly to have two copies of esstially the same thing. I agree. Maybe it's time to break-up the OpenGL package into several parts: To be honest, I don't really care how it gets packaged. But I will be glad to help if it attains an end. API to native Windows OpenGL implementation, accessible through M$'s opengl32.dll could be in the w32api package, as it is now. The GL include directory could be in /usr/include/w32api exclusively, without need for another in /usr/include. That sounds reasonable. Would you make a sym link from /usr/include/GL to /usr/include/w32api/GL then? API to GLUT could be in a GLUT package, while the GLUT32.dll could be in a GLUT-runtime package. They are so small that it seems overkill to break them up. API to GLUI and GLUIX could be in a GLUI package. There is no dll for both of these. They are C++ static libraries that would need to be repackaged each time that the C++ interface changes, as has been the case between g++ 2.95, 3.2, and now 3.3. I hope that this interface will remain stable for a while now. I have never used these. I understand your pain with C++ ABIs, though. Are there any plans to update Cygwin's OpenGL headers to include 1.3 or 1.4 support? Be it via using the w32api Mesa ones, or by other means. Let that be clear: headers alone will not provide access to OpenGL 1.2+ functionnality. You will still have to program the loading of OpenGL extensions, if they are available from the graphic card driver. Maybe something like extgl (http://www.levp.de/3d/index.html) could be packaged for Cygwin to make that easier. Sure, I know headers don't magically create functionality. They just allow access to that which already exists. But, most vendors these days (ATI Nvidia) provide 1.3 or 1.4 functionality. It would be nice to use it without jumping through hoops. The way you added support for OpenGL 1.2 via a define would be fine. BTW, what version does Microsoft ship with XP? Is it still 1.1? I don't have a clean XP install to check. As for the extension loading library, it's a don't care for me. Are there any plans to update Cygwin's glut to the current Nate Robins version? Could be done; however, it is nearly 2 years old and provides no new functionnality. It is sad, but GLUT is dead. There is a project in sourceforge for a replacement: freeglut (http://freeglut.sourceforge.net/fg/), but is still IMO too buggy for prime time. However, it is actively developped and debugged, and a stable release is supposed to come real soon. Yeah, I know regular glut is dead. I have looked at freeglut before and it looks interesting, but I will take your word for it that it is still too buggy. There have been significant changes since the glut version in Cygwin (3.7.3 Sept. 27, `00 now 3.7.6 Nov. 8, `01). I'm not entirely sure if they are benneficial. I've listed them below for anyone that's interested. Maybe we should just wait for freeglut to stabilize, though. (Nov 8, '01) x Changed fullscreen mode from TOPMOST back to simply TOP, since (it turns out) many people use windows atop a GLUT window. (Nov 8, '01) x Added code to prevent CPU spiking when no idle function is registered. Otherwise, if an idle function is registered, spike CPU so that the idle function gets all the attention it needs and if this is a problem on the program side, the user can stick a sleep() in their idle function. I believe that this strikes the best balance betweeen GLUT being fast, and also being nice to other processes. Thanks to James Wright for reporting this bug. (Nov 8, '01) x Fixed bug in motion callback handler which wasn't setting the current window, so multiple window apps (e.g., any GLUI app) wouldn't get the callback correctly. (Oct 4, '01) x Fixed bug in glutEnterGameMode() that caused new windows to not be in fullscreen mode, so they got window decorations. (Oct 3, '01) x Fixed bug in getVisualInfoFromString(): visuals not reloaded on display mode change. Reload visuals each time they are queried. This fixes a problem with Win32 because the list of availabe Visuals (Pixelformats) changes after a change in displaymode. The problem occurs when switching to gamemode and back. Thanks to Michael Wimmer for pointing this out providing the fix. (Oct 3, '01) x Fixed bug in XGetVisualInfo(): pixelformats enumerated incorrectly. Passing 0 as a pixelformat index to DescribePixelFormat gives
