Michael Gold wrote:
|
| - Application wants to render to windows on two seperate displays, A and B.
| - A is local to the app, B is remote
| - Both servers support extension GL_EXT_foo
| - App queries glFooEXT() from GLX client - succeeds
| - App queries extension string from server B
| - App calls glFooEXT() when trying to render to B
|
| This will fail if the local client is unaware of the protocol for
| glFooEXT(), and there is _no_ way for the app to predict this.
I'm not sure I follow your example, but so far I don't believe there's
a problem.
The GLX extension-query mechanism returns the intersection of the
extensions supported by the server and the extensions supported by the
local GLX encoder. So there's no way for a client to be told that a
remote extension exists if the local GLX encoder is unable to generate
the protocol.
As for the function pointers, I wouldn't expect any substantial
difference between the local and remote cases. For a remote context,
the local GLX encoder just presents the same function dispatch table
that a local driver would present. If the client app calls a function
that the GLX encoder doesn't support, then it gets the same behavior
that it would if it called a function that a local driver doesn't
support. (No-op or abort(), depending on the outcome of our
investigations into calling sequences.)
What have I missed?
Allen
