> Adding a windowing API to OpenGL means that you have to *have* a
> window system on any target platform, which is an unreasonable
> constraint on e.g. embedded or small-footprint or dedicated devices.
I don't understand why adding a windowing system then
requires that you *have* to have a windowing system for other
portions of OpenGL to work. If they work now without a windowing
system - or work well with the "abstracted" windowing systems
mentioned as compatible, then surely it could work with or without
such an abstracted api if it was originally provided as part of
Quote:> It's also inappropriate for dedicated "render server" type applications
> where OpenGL really is used only for rendering on systems that may not
> even have a graphics head.
See comment (question) above.
> For those platforms which do have some sort of window system, you
> would be doing all the work of writing yet another WS which doesn't have
> the platform's native look and feel, may not semantically map well onto
> the native WS, and certainly won't encompass every last capability
> specific to that WS.
I certainly don't want that. I am still wondering why it was
not provided with an encapsulation of the windowing system native
to that platform. Thereby, if on motif - it looks like motif, if
on NS it looks like NS - etc...
> Finally, forcing a new WS on OpenGL licensees would have been a
> formidable barrier to adoption, while enabling it to work in the
> platform's own environment has resulted in OpenGL being available on
> Irix, HP/UX, AIX, BeOS, MacOS, Linux, Solaris, Digital Unix, Windows 9x,
> NT, QNX, and many other platforms.
The original IrisGL call: winopen(), certainly was able to
provide a window that didn't conflict at all with the Irix/X look
and feel (unless the programmer wanted it to). Why would the same
"shell" around appropriate code on other platforms produce windows
which do? Especially since the character of the windows mentioned
above on any of the X based systems is already encapsulated largely
by the desktop manager they are running.
> But there are a bunch of OpenGL-friendly libraries like GLUT, MUI,
> PUI, GLUI, Tk, fltk, Forms, etc. which offer portable windowing
> abstractions and toolkits of several types. Some are layers on the
> native GUI which let you construct OpenGL "widgets" of some type, and
> some are built on top of OpenGL itself. If you just want to do basic
> OpenGL stuff or have only modest 2D GUI needs, GLUT with one of the
> widget libraries like GLUI is great; for more aggressive interfaces look
> at something like Tk or Forms.
No argument. I have used several of these alternative with
varying degrees of success to provide windows for OpenGL on various
Jon, I am sorry if I seem argumentative - that is not my
intent. You have indeed provided some insight into the decision.
Part of my "rant" has more to do with the shift in markets for
3D interactive programming. Once upon a time, all of us were asked
to port our IrisGL progs over to OpenGL so some mucky muck could
see the product viz on his windoze box. Suddenly I was up to my
elbows in windoze code (SDK/MFC), which after a few years of the
sensibilities of IrisGL/Performer/Inventor/X11/Motif/etc... seemed
arbitrary, unnecessarily difficult, and just plain badly done.
I have just been looking through some old IrisGL code and
finding that it only took a handful of lines (often two) to open
and make a useable window:
To replace that with the MFC (or even Motif) equivalent, was a
real pain (see the three page microsoft example for "hello world").
Yes, the appearance of crossplatform GUI toolkits that work and
seem to be staying around for a while, has helped considerably. But
back when this decision was made few of these existed, fewer were
stable, and most have already gone the way of such things.
In the end, I wrote the code, got it working, encapsulated
it myself, put it in a library, and hoped I would never have to
see it again, and went went on to write the code I was being paid
to write in GL.
Don't let the cows fool you!