On Mon, 20 Sep 1999, Bob Beretta wrote:
> > Since the behavior described is optional, and GLUT programs are by
> > definition meant to be portable, how does this work? Are all of these
> > GLUT apps relatively simple so they just happen to work in this
> > environment?
>
> The behavior is optional at the AGL layer, but when we ported GLUT we had
> to make a decision so we enabled multi-head support by default. If we actually
> encountered a GLUT app that broke we might reconsider the default setting or
> make a user control panel for setting defaults in the GLUT library.
>
> It's not so much that the GLUT apps are simple, but that the behavior required
> to break the system is somewhat unusual. The real hole in the system (as Stephen
> Baker pointer out) is when an app is dependent on particular maximum values
> from glGet*, like MAX_CLIP_PLANES or MAX_LIGHTS. Most (all??) GLUT
> apps in the distribution just assume the OpenGL minimum values for these so
> they don't have a problem.
Yikes!
So my portable GLUT-based programs that people are currently running
are working more by luck than judgement!
Yikes again!
This could explain MANY problems that people have reported to me
on MacOS platforms.
GLUT programs don't only come from "the distribution" (whatever
that means). There are some quite complex programs like FlightGear
and Tux_AQFH that use GLUT. Both of those (for example) use
Proxy texture commands - which are clearly going to be flakey
in this setup.
Well, this is clearly off-topic for this *Linux* discussion,
but I'd definitely like to protest this approach. (Not that I
know what the RIGHT approach is mind you... :-)
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
