At 01:22 PM 10/14/99 -0500, you wrote:
>On Thu, 14 Oct 1999, Michael I. Gold wrote:
>
>> In case i'm confusing anyone with my stance, I feel we must have one of:
>>
>> a) context-dependent glGetProcAddress (can we handle remote GLX with this?)
>
>I'm not wildly keen on this one because of the number of dumb
>users who are going to screw up because of calling it before
>a context has been established. However, I could live with it.
Hopefully people know by now that you must have a context before you call
glAnything! If they mess up, they'll crash, they'll learn, and they'll fix
it. :)
>> b) context-independent glXGetProcAddress
>
>Perhaps - It's not my favorite - but it'll do.
This seems to be the least contentious anymore.
>> c) context-dependent glXGetProcAddress
>
>This one is my least favorite - because you have to
>use glXGetProcAddress to query for glX functions too,
>since those are context-independent, you now have:
>
> Q: "Do I have to have a rendering context to
> call glXGetProcAddress?"
>
> A: "It depends on what you are asking it, for
> glX functions - no, for gl functions - yes"
>
>Uck!
Yah, this same situation exists under Windows today.
So lets go with (b), I think this will satisfy the majority, if not everyone.
i) We have context-independent entry points, which some (not including me)
feel is important*.
ii) As a GLX function, it will be in the right place to handle the
requirements of a remote extension protocol mechanism.
iii) No impact or ramifications for Windows, which has different semantics.
*In reality, people interested in supporting both X and Windows will have
support for context-independent pointers, wasting the gyrations we go
through to support context independence in the implementation. But, oh
well, I seem to be in the minority on this point, and will yield.
-- Michael
