[HOpenGL] HOpenGL1.02 on Sun's?

[Sven Panne]

C. Reinke wrote:
> [...] I'm not at all sure I understand the connections properly.

Scenario 1: The client library and the X server both "speak" GLX.
In this case, the actual drawing is done in the server (which must have
OpenGL support) and relatively little data has to be transferred between
the client and the server. This is how your client application linked
with SUN's OpenGL tries to communicate with your Exceed. But this fails
obviously if the Exceed server is not GLX-aware.

Scenario 2: The client doesn't use GLX, but does all rendering for itself
and transfers all image data through the "normal" X protocol to a "dumb"
X server. This will work with all servers, but more slowly due to the high
volume of data which has to be transferred. Mesa can fake the GLX protocol
in this way.

(Well, there's another scenario, see http://dri.sourceforge.net/, but
this doesn't matter for our discussion.)

> [...] That is just the *extensions* registry - the API itself is now in
> the hands of the ARB, and the specs there do not seem to define any
> values, only their names?

Even if this was the case, this is a rather hypothetical discussion. Let's
take e.g. the M$ platform: In ancient times there were two OpenGLs on M$,
one based on the sample implementation and one for plugging in vendor-specific
DLLs. They are binary compatible, as is Mesa on M$, the same Mesa which is
available on Linux, SUN, etc.  All are binary compatible without any
platform-specific redefinitions for OpenGL tokens. This is a must, because
OpenGL is rarely statically linked into an application.

And another reason: "Normal" OpenGL functions are handled not much different
from extensions, you can get their address via the standard mechanism etc.
This is how our favourite 3D shooters handle switching drivers at runtime.

> [...] GHC has otherwise become quite independent, but HOpenGL seems to
> depend on cygwin?

No, it's just the build process that depends on the standard Unix tools.

> And are the executables dynamically linked to OpenGL, so that they have
> a chance to work with someone else's graphics-card?

Yes.

> In brief, could I "ship" a windows-executable to non-Haskellers and hope
> for this to work (and not ruin their hardware?-)?

Again, yes. Currently the cygwin DLL is needed, too, but tweaking HOpenGL
to be cygwin-free should be possible.

Cheers,
   S.