RE: [oglbase-discuss] OK, back to Re: 2nd draft:GL_EXT_get_proc_address spec

[Thomas Roell]

In your message of 17 September 1999 you write:

> By the way, I believe we have been focused on direct renderers only.  How
> does this all play in an indirect rendering context?  We need both client
> side and server side dispatch, not to mention protocol for unknown
> extensions.  How does this requirement affect the discussion of context
> dependent vs independent functions?  I think this necessarily dictates that
> we talk about a glXGetProcAddress rather than glGetProcAddress.  Apologies
> if this has already been discussed, I don't remember it and can't find
> mention of a proposal in the current spec.

That is a very good questions. The X-Server side is pretty trivial, as
a driver would just supply the decoding part to the GLX decoder in
form of a dispatch table entry. This table might be big (aka 64k
entries), but rather simple to handle.

The client side is more tricky. There are probably three ways to solve
that:

1. Not deal with it, and not support the extensions.

2. Allow some binary code to be loaded into the libGL.so to add the
   encoder part.

3. Have a private GLX Vendor extensions to query the X-Server for a
   protocol encoding template, which allows libGL to dynamically encode
   the protocol (something like XDR). 

- Thomas
-- 
             Thomas Roell   /\         An imperfect plan executed violently
             Xi Graphics   /  \/\ _     is far superior to a perfect plan. 
         [EMAIL PROTECTED]   /   /  \ \     
                         / Oelch! \ \             George Patton