----- Original Message -----
From: Jon Leech <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 08, 1999 12:49 AM
Subject: Re: [oglbase-discuss] New GLX_ARB_get_proc_address specification
> Oh, one more implementation thing - it's conceivable for the *app*
> to supply the GLX protocol encoders for extensions that the app uses
> (which it has to know about, after all) and that remote servers know
> about, even if the local client libraries don't. Again some mechanism
> would have to be created to hook it into client GLX and dispatch.
that would be a nice idea for an extension... hmm that's another topic
though.
>
> But really I think the only reasonable answer is that the app gets
> only those extensions on indirect contexts that are supported by the GLX
> in libGL.so. Even having encoder functions in the driver DSOs is going
> to be darned tricky.
>
> Allen's point about calling conventions and stack cleanup puts the
> death blow to the feasibility of generic-error or -noop routines for
> unrecognized extension names, anyway.
I see your point for error setting. If you don't even have enough
information to know how to report an error (is the missing extension a glx
or gl call) you certainly can't do so transparently. I'm not sure what the
problem would be dispatching to a generic noop in that case in terms of the
call stack ( i must have missed that post) -- and if one cannot do so then
Michael is right context-independant may be too much of a hassle.
Especially given that use of EXT's unknown to the client lib in a
heterogeneous, multihead, Linux environment is a bit of a "corner" case.
=========================================
OUTSIDE THE BOX THINING ALERT
=========================================
Maybe a better solution for those who think of this as vital would be to
support some sort of add-on static link-library (lets call it the client
patch library) which would embody all the EXT, noop, error-handling, GLX
encoding et. al. for a known set of extensions (for example a OpenGL 1.2 or
a "common games card extensions" or the "omnibus extension client patch
lib"). The client patch library would allow the application to link to these
extensions as if supported in the client lib, but hide platform (wgl vs.
glx) specific details. One would simply initialize the client patch lib
when creating the context and make sure the client patch lib knows about
changes to the current rendering context. Either this would require the app
to do some sort of "makeCurrentEXT" when changing the current context or be
built on some sort of callback registration extension s.t. the client patch
library would be able to know when the context changed (for platforms with
context dependent procs). Were one to take this approach, then the
motivation for context independence of returned procs is substantially
reduced, and the ability of applications to take advantage of new extensions
would be greatly increased. In a open source model, for each extension the
extension author would simply implement the api/encoding in the client patch
lib source making calls to the getProc'd functions as appropriate.
Applications developers then simply include the most recent (or appropriate)
version in their applications, calling them as if part of the client lib
itself. The down side is an extra layer of indirection. The upside is that
new features are more easily included and adopted by applications, and that
the getProc / extension proc mechanism could be made simpler to implement,
with the client patch lib hiding the details for all but the bravest and
most demanding developers.
This would seem to be simpler than adding all this mess^Wmass to the driver
and client lib -- yes? Thoughts?
