Stephen J Baker wrote:
On Sat, 11 Sep 1999, Brian Paul wrote:
How do we make decisions on these things when there's no
obvious, clear answer?
I think we have a choice between two approaches:
* Separate calls : Logically more tenable, clean.
* One call : More windoze compatible.
Keith Whitwell writes:
- Contexts are well specified and will have to be mastered
- Context dependent pointer results are not a new concept
applications [need] to do their own branching
if they use multiple contexts
I agree. I fail to see how application-side management of
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
Richard Pimentel wrote:
Brett Johnson wrote:
Richard Pimentel wrote:
Stephen J Baker wrote:
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
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? Context switching is expensive,
so assigning cached pointers from a per-context LUT to the
global variable (better than
Looks almost perfect to me. Two minor isses:
1. What does GetProcAddressEXT return for core API functions if they
are not supported by the library implementation ? Assuming there
is a OpenGL 1.1 based libGL and you query a 1.2 function. Does a
non-NULL value imply that the function
On Fri, 10 Sep 1999, Jim_Cobb wrote:
Why do we use a pointer to GLubyte for the procName? This prevents
the following from compiling on my machine
int
test_it()
{
void (*tst)() = glGetProcAddressEXT("foo");
}
I get the error
cc-c foo.c -o foo.o
In your message of 10 September 1999 you write:
2. Having a bound context, while retrieving the function pointers is
kind of difficult to handle for applications. There are
applications which create first all the contexts they need, before
actually making them current. Hence
Stephen J Baker wrote:
On Fri, 10 Sep 1999, Thomas Roell wrote:
? Looks almost perfect to me. Two minor isses:
?
? 1. What does GetProcAddressEXT return for core API functions if they
? are not supported by the library implementation ? Assuming there
? is a OpenGL 1.1 based
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
Attached is the second draft of the spec for GL_EXT_get_proc_address.
It incorporates everything I've been able to gather from today's
discussion (so far). I think I've learned a lot today!
This file is under revision control in the Mesa CVS repository in
the docs/ directory, BTW.
-Brian
Name
11 matches
Mail list logo
