Michael I Gold wrote:
>
> At 05:32 PM 10/14/99 -0600, Brett Johnson wrote:
>
> >> On the flip side, does it make sense to even call GetProcAddress before you
> >> have queried the existance of an extension? I think not.
> >
> >I can think of at least one instance where it makes sense:
> >
> > - You're writing a library. At initialization, you want to gather all of
> > the function pointers you might call later (depending on whether the
> > associated extension is supported).
>
> I suppose its a matter of style. I would query for extension support
> before querying the entry points themselves. There's no reason it can't be
> done in the other order, besides aesthetics.
You're correct. All I was trying to point out is that does "make sense" to call
GetProcAddress before a context is bound. It's not strictly necessary, but
then neither are context independent pointers.
> >> And synthesizing
> >> the GLX protocol requires an implementation to provide a template; the
> >> client side GLX can't do its initialization work unless an implementation
> >> is present. I suppose this can all be done at process initialization time,
> >> when each driver registers itself with the GLX. Sounds like a pretty
> >> heavy-weight initialization though. Maybe we should stick with context
> >> dependence, hehe. :)
> >
> >I don't understand the point you're making here Michael. There is a fixed
> >amount of initialization overhead added to every context creation in order
> >to support context independent pointers (i.e. the driver must "register" all
> >of its supported entrypoints). Why would this overhead be any different for
> >an indirect context? Am I missing something?
>
> What does GLX do when GetProcAddress is called for a remote display? It
> must set up a wrapper proc to dispatch over the wire. It must know the
> protocol. It can only know this by querying an implementation which
> supports the extension. It only needs this from one supporting
> implementation, since it will be the same for all, but it cannot do this
> work without it.
Oh, I think I see the disconnect here. I'm thinking of protocol as just another
"driver". It would "register" itself to the dispatcher, just like any other
driver, at context creation time. At that time, the protocol generating
routines would be set up. So, GetProcAddress and the dispatcher don't know
anything about protocol, and don't care. And GLX doesn't know anything about
GetProcAddress, and doesn't care.
When GetProcAddress is called with a new extension, it only allocates a
dispatch stub. If there is no currently bound context that supports the
extension (which is the case by definition when GetProcAddress is allocating
a new stub), then the stub is initialized to point to a routine that sets an
error and returns. When a context that supports the extension is bound (whether
the context is indirect or not), the stub gets re-initialized to point to the
correct "driver" routine to handle the call (i.e. the protocol generation
routine that understands the extension protocol, if this is an indirect context).
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
