Brett Johnson wrote:
> Richard Pimentel wrote:
> >
> > Stephen J Baker wrote:
> > > Look at it this way: All of the other gl* functions are assumed to
> > > be "in the present context" - why should glGetFuncAddress be any
> > > different?
> >
> > We can live with this. Just spell this constraint out clearly in the function
> > spec. To tighten things up even more, will a function pointer be allowed to
> > ever become invalid within the context that was current when it was queried? I
> > would say no. What is the behavior of a call to a function pointer after its
> > context is deleted? Crash the app. I hope since this would be a very bad bug.
> > It is sort of analoguos to dereferencing stale pointers.
>
> As I see it, the problem is exactly the opposite. I.e. it would be a very
> subtle bug for an application to get a function pointer in context A, then
> call it in context B.
I think they both would be subtle bugs whose impact could be felt several frames
later. This tough problem and I agree that having the implementation track which
context is current and dispatch to the correct underlying function frees up the app.
But I have two concerns:
* The inefficiency of the extra function call to the context neutral function and
the deference that function has to do to get to the "real" function.
o If the app. has the burden, there is just the indirection from its
internal per context record where it stores its function pointers. This
isn't fun for the app. and maybe the extra call overhead isn't that
important, but there is a price to pay no matter how you slice it.
* The complexity of trying to manage this in a heterogeneous environment with
multiple heads not supplied by the same vendor.
o This one would go away if we put the stick in the ground and said function
pointers are only valid on the same display. But even this has all the
same issues the per context constraint.
>
>
> Must we now require that every OpenGL function whose pointer is returned by
> "GetProcAddress()" check to ensure that it's being called while the same
> context from which it was obtained is current? Wuf, I hope not. That would
> be an awful performance penalty.
So I must be missing something. How would you implement the extension function foo
to be context independent? Seems like context independence is more of a performance
hit than this test for the correct context. But maybe I am just stuck on one
implementation.
>
>
> If we don't require this behavior, we have to say that the behavior in this
> situation is undefined. The function can't set a glError if it hasn't
> checked to see if it's in its own context, so it would just do its normal
> thing, assuming that it owns the current context. It might crash the
> driver if the developer is lucky, or worse, it might just silently change
> some unintended context state that won't be noticed until 5 frames later (or
> until the app user turns on some currently unused feature that relies on said
> state). Yuck... This is a potential nightmare for app developers.
Yep. But it wouldn't be the first one or even the worst one ;-). That is why
company's like Rational make a lot of money. We need an OSF "ZAPdb" that would catch
this kind of stuff.
>
>
> Cheers!
--
Richard Pimentel
Manager of Graphics and Integration
Industrial Design Products
Parametric Technology Corp.
540 Arapeen Drive, Suite 100
Salt Lake City, UT 84108
(801) 588-4668
