Thomas Roell writes:
> > > foo_2() { (*rect)(0.0, 0.0, 1.0, 1.0); }
> >
> > If you just change rect every time you change the current
> > context, you should be fine?
> The problem with that is that it leads to a lot of bugs.
> If the dispatching is done behind the scenes this is a
> non-issue. If it's in the hands of an application writer,
> it is a big problem.
I am at a loss. Now I live in a world of few contexts, so
maybe my reasoning is wrong, but as we seems to be stuck
at this point, maybe I'll describe my solution, and somebody
points out where I'm naive.
1. There is only one current context (*)
2. An application using multiple contexts has
to initiate a GLX MakeContextCurrent to enable
a given context
3. An application could thusly encapsulate all
context-specific maintenance inside a
My_MakeContextCurrent abstraction
4. A multi-threaded application has to sync
context switch with thread switch, again
My_MakeContextCurrent does all maintenance
required.
5. A single context, single thread application can
avoid all such overhead, as it is not inherent
to GL
A C++ implementation would be straightforward (like
e.g. the proposed Magician JavaGL bindings). If you
use C, and your application loads the DLL, and loads
the entire core API using GetProcAddress, you could
hide the entire indirection behind
// Global variable.
void (*glVertex3f)( GLfloat x,y,z );
not linking against a particular library at all. The
only maintenance effort I can see is:
void My_MakeContextCurrent( whateverType contextHandle ) {
// Do the GLX (WGL) MakeCurrent thang
...
// Now update all the pointers.
#ifdef CACHED
My_SetAddrsFromCachedLUT( contextHandle );
#else // dynamic, string LUT, yuck
...
glVertex3f = glXGetProcAddress( "glVertex3f" );
...
#endif
I have John Carmack's permission to release the Q2 DLL/GL
loading code. It exists in a Win32 and a Linux variant,
and before this list got started I had written a portable
version (using a VID_GetProcAddress, no less :). I am
tempted to extend my equivalent of My_MakeContextCurrent
by caching contexts.
I can see that having to write this is a major pain, but it
is so generic that we could easily put something like this
Q2 code in the public domain for those who really shy away
from implementing their own Context+ProcAddr maintenance.
For C application that want to link instead of load, the
global function pointers will need a different prefix though.
I don't see a "big" problem here. I see a problem that has to
be solved in some variation of the above, and our discussion
seems to revolve around the question whether this solution
has to be inherent part of GL, or is a maintenance structure
the application has to implement. I don't know what's best,
but my personal preference is clearly not to make another
call indirection mandatory part of a call intensive API,
and to put the (IMO acceptable) burden of maintenance on
those who consider themselves capable of juggling multiple
contexts.
As somebody else put it: "we can live with this, just spell
it our clearly". If you can't keep your pointers valid,
chances are you just as well omit a MakeCurrent by accident.
b.
(*) presuming GLX 1.1. I have yet to digest the ps/PDF
specs of 1.3, and incidentally I do not know
whether e.g. the GLX pbuffer extension with different
contexts for draw and read breaks this assumption?
