Since this has gone way off-topic, I changed the subject.
Stephen J Baker wrote:
> On Mon, 20 Sep 1999, Bob Beretta wrote:
>
> > 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.
A single example of a GLUT app that fails on the Mac due to multi-head
issues would be greatly appreciated. This is, after all, the office where all
such reports end up if the issue is worth reporting. There are known problems
with GLUT on the Mac - they all have to do with the very different windowing
and menuing systems (no child windows, no per-window menus). None that
I have logged are related to the multi-head system design.
GLUT is not OpenGL or a core Apple API and we don't have the burden of
strict compliance, so I am not claiming that *anything* implemented blindly on
GLUT will work properly with multi-head. I am certain that any "quite complex"
GLUT app would need a little tweaking to get its windowing working properly
under Mac GLUT, and any such app *may* choose to disable multi-head.
It's an optional, platform-specific feature - if you don't like it, don't use it.
> 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.
Proxy textures are not affected by the multi-head issues. They are issued
to all drivers hooked to a context.
> 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... :-)
Yes we have diverged, but only the GLX portion of the get_proc_address
discussion is Linux-specific. GL_EXT_get_proc_address affects everyone.
Protest away.
Bob Beretta
Apple Computer
