Stephen J Baker wrote:
> On Fri, 10 Sep 1999, Thomas Roell wrote:
>
> ? ? OK - but you still have to call the gl version from the context in
> ? ? which you'll call the function that it returns. (That would certainly
> ? ? HAVE to be the case for EXT functions - so we might as well make
> ? ? it the rule for all functions - if only to simplify the manual!)
> ?
> ? It's still an ugly problem. For an application programmers point of
> ? view, I really don't like the idea of GetProcAddress() be dependant
> ? upon the context it's called under. It's just a nightmare and a
> ? predictable recipe for disaster. On the other hand, letting libGL do
> ? the indirection for unknown extensions is very tricky.
>
> On the other hand, MANY programmers only ever work in one context,
> and if they use GLUT, they aren't even aware of the existance of
> contexts and such.
Huh? I am sorry but that is naive. I would argue just the opposite. Industrial
3D apps use many contexts and really grind through them. One of our apps uses
13. Contexts to us are very expendable and are used for all sorts of things.
When we ported from UNIX to Windows, context switching bugs in libgl were one
of our biggest hurtles. Windows Ogl implementations have matured to be on par
and often better at this than their UNIX competitors. Many of the big
commerical 3D apps are starting to take a very close look at Linux as a new
platform to deliver products on. The demands they will place on Linux Ogl
implementations will be very significant.
>
>
> Relatively few programmers (I suspect) are into multiple contexts,
> and if they are, will be painfully aware of the consequences of
> getting things like this wrong.
>
> Look at it this way: All of the other gl* functions are assumed to
> be "in the present context" - why should glGetFuncAddress be any
> different?
We can live with this. Just spell this constraint out clearly in the function
spec. To tighten things up even more, will a function pointer be allowed to
ever become invalid within the context that was current when it was queried? I
would say no. What is the behavior of a call to a function pointer after its
context is deleted? Crash the app. I hope since this would be a very bad bug.
It is sort of analoguos to dereferencing stale pointers.
>
>
> We are not demanding to have:
>
> glGetError ( context, ... ) ;
> glAreTexturesResident ( context, ... ) ;
>
> ...etc?
>
> Is this really all that different?
>
> 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
--
Richard Pimentel
Manager of Graphics and Integration
Industrial Design Products
Parametric Technology Corp.
540 Arapeen Drive, Suite 100
Salt Lake City, UT 84108
(801) 588-4668
