Jon Leech wrote:
>
> On Thu, Nov 04, 1999 at 02:58:47PM -0700, Brett Johnson wrote:
> > I agree that it is possible to come up with a mechanism to find all
> > possible 3d drivers, then query them to determine which extensions they
> > support. But it seems like a lot of work to me, and I don't see any reason
> > to do it.
>
> Which is equally true for the context independence issue to a good
> number of us, so I don't think a "lot of work" objection is in and of
> itself sufficient.
Touche... ;o) But in this case, it really _is_ a lot of work! ;o)
> > What is your reasoning for wanting a NULL pointer to indicate
> > that "no currently available driver supports this extension"?
>
> That's what most of my last two posts were about, but to summarize:
Sorry, I should have read your posts more carefully. Now they make
perfect sense to me!
> it is misleading to the application, noop behavior creates debugging
> nightmares, and no reasonable error behavior appears possible.
These same arguments apply to calling a function when the underlying
driver doesn't support it, but another driver does (i.e. returning a
context-independent routine in the first place). I think it's perfectly
reasonable for the implementation to set a glError (or glXError) if one
of these functions are called inappropriately (i.e. in a context that
doesn't support it). This behavior would address your concerns, and
it's trivial to implement.
> IMO this is dlsym() on steroids to handle the loadable driver issue
> - not a precognizant API that anticipates everything you might ever want
> to do in a GL app. If the function exists somewhere in the
> implementation, you should be able to get at it. If not, why pretend
> otherwise.
I think we have a fundamental difference in perception of this thing. To
me, we aren't returning the actual function that implements the extension,
like a dlsym on the appropriate driver library would. Rather, we're
returning an opaque function that, if you call it in an appropriate context,
will execute the appropriate implementation of the extension/entrypoint.
We've already established that if this returned function is called in an
inappropriate context (i.e. where its associated extension isn't implemented),
nothing happens (or an error is set would be my preference). I still don't
see a reason to complicate this definition (and the implementation) further
by introducing the concept of "this extension isn't implemented in any
context you might be able to create later".
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
