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

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

[Andre Bleau]

Brian Ford wrote:

>Andre Bleau wrote:
>...
> >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?

No; if /usr/include/GL does not exist anymore, gcc will look in 
/usr/include/w32api/GL for #include <GL/gl.h> directives.


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

I think you are right. Separating the lib (.a) and headers (.h) from the 
GLUT dll would only save a few Kbs for those who wants the dll.


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

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.


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

I do. It is still 1.1. I guess that M$ is so involved now with DirectX that 
they will never update the OpenGL dll.


>As for the extension loading library, it's a don't care for me.

Then, I guess you never had to work with extensions...


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

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

What do you think?


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/

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

[Igor Pechtchanski]

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.html>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.
>
> 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/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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)

[Nigel Stewart and Fiona Smith]

> 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 (Earnie, please read this)

[Brian Ford]

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 (Earnie, please read this)

[Igor Pechtchanski]

On Tue, 30 Sep 2003, Andre Bleau wrote:

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

Well, I was actually thinking of the GL library having a wrapper for each
function that did the check and either called the real function or failed.
The UNIX code won't change at all, and the wrappers in your library will
initially look like Option A above.  Then whoever needs the functionality
can send you implementations of "myOwn2000LinesOfCodeFunction"s, which you
can add as you see fit.

> [snip]
> > > - 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.

Sure...  You could coordinate the recompile with a major release, and then
name the DLLs after the older version that each represents (e.g., see
openssl-096.dll).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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)

[Brian Ford]

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/