On Thu, Nov 04, 1999 at 05:49:45PM -0700, Brett Johnson wrote:
> What's wrong with setting GL_INVALID_OPERATION?
To quote what I've said several times before in different ways, with
added emphasis (sorry if I'm sounding a bit testy here, but I'm getting
tired of repeating myself, and am wondering if there's something unclear
about what I'm saying):
> No useful runtime error behavior is possible given that the pointers
> may be to any of GL, GLX, or perhaps GLU functions. GL and GLU calls
> would raise a GL_INVALID_OPERATION error, while GLX would generate an X
> error. As none of the existing GLX error codes describe this situation,
> we'd have to create a new one.
>
> Which is it supposed to be for a function identified by a string
> name which is not known to be of either category, and which the
> implementation has no idea how the application intends to use? IT'S
> IMPOSSIBLE TO MANDATE RAISING A GL ERROR WHEN THERE MAY BE NO CURRENT
> CONTEXT, but no application is likely to query for GLX errors in the
> middle of its rendering loop."
> > > TBD. Adds consistency at the cost of a much larger lookup
> > > mechanism.
>
> Actually, I think the lookup mechanism would be dramatically simplified,
> since it wouldn't have to be special cased to not return a subset.
My model is looking up a symbol in a dictionary. The size of the
dictionary varies with the number of entries. This assumes that we are
not returning non-NULL pointers for nonexistent function names; if we
*are* returning them then the cost calculation is as you describe. I
don't care much myself but the issue has been brought up before in the
discussion by others.
Jon
