Re: Future of OpenGL package

Re: Future of OpenGL package

[Brian Ford]

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
       unpredictible results (e.g., this fails on the Voodoo opengl32.dll
       and always reports 0 as the last available pixelformat index).
       Thanks to Michael Wimmer for pointing this out & providing the fix.

    (Oct 3, '01)
    x  Fixed bug in glXGetConfig(): pixelformats enumerated incorrectly.
       The test was OpenGL support OR draw to window, but should be AND.
       Thanks to Michael Wimmer for pointing this out & providing the fix.

    (Sep 28, '01)
    x  Fixed glutChangeToSubMenu()/glutChangeToMenuEntry() bug where if you
       went back and forth between a submenu and a plain entry, the submenu
       wouldn't be updated properly.

   (Sep 28, '01)
    x  glutSetIconTitle() is now a nop.

    (Sep 28, '01)
    x  glutFullScreen() now sets the window as TOPMOST, therefore, the
    window will always be on top (this essentially disables alt-tabbing).

    (Sep 28, '01)
    x  The key repeat ignore flag is now honored correctly.

    (Sep 28, '01)
    x  Key presses are now reported more accurately and fully, in
       particular, modified up events (i.e., SHIFT-2) are now reported
       correctly.

    (Sep 28, '01)
    x  Subwindows nested arbitrarily deep get their keyboard callbacks
       correctly now.

    (Sep 28, '01)
    x  Major rewrite of the window procedure code to clean it up and make
       way for other bug fixes.

    (Sep 23, '01)
    x  Fixed noof example program to use RAND_MAX instead of assumed
       max of 2147483647.0.  (Now it looks _much_ better!)

    (Sep 22, '01)
    x  Fixed sunlight example program.  globe.raw data file was corrupt,
       added a new one.

    (Sep 22, '01)
    x  Fixed zcomposite example program to print message if overlay
       support is not found (instead of crashing).

    (Jan 22, '01)
    x  Fixed malloc(0) bug in Win32 version of XGetVisualInfo.  Thanks
       to Kekoa Proudfoot for bringing this to my attention.

    (Dec 12, '00)
    x  Added data files for the advanced & advanced97 programs.

    (Dec 12, '00)
    x  Added Developer Studio 6 project and workspace files for pretty
       much everything (the stuff left out was usually unix specific).

    (Dec 7, '00)
    x  Fixed several compilation problems & corrupt files.  Thanks to
       Alexander Stohr for bringing these to my attention and providing
       detailed fixes.

    (Dec 6, '00)
    x  Fixed compiler support for lcc.  Thanks to Gordon for bringing
       this to my attention and debugging fixes.

    (Nov 8, '00)
    x  Fixed submenu problem (sometimes the menu callback was not
       called for valid items).  Thanks to Michael Keeley.

    (Oct 16, '00)
    x  Corrected corrupt duck.iv file.  Thanks to Jon Willeke for finding
       this problem.

-- 
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]

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

[Andre Bleau]

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 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/