At 05:42 PM 9/9/99 -0400, Brian Paul wrote:
>If the address of an extension function depends on the context then that
>implies, for example, that
>&glPolygonOffsetEXT != glGetProcAddressEXT("glPolygonOffsetEXT")
>for some context(s).
If there is a static glPolygonOffsetEXT then there is a common dispatch
table for this routine. I'm operating under the assumption that:
- not all extension API's are in a common dispatch table, and
- its possible for two implementations to co-exist (e.g. multimon)
If either of these assumptions are false, there is no reason to have
per-context or per-visual pointers. Is my thinking too windows-centric here?
>I think that's pretty weird. I've worked on an OpenGL application which
>deals with several simultaneous GL contexts. Extension handling is
>complicated enough without having to worry about context-dependant
>extension function pointers.
Agreed, in the common case this is not a problem, how often do
multi-context apps render to multiple different visuals? I believe we are
talking about an uncommon corner case and just want to be sure we don't
spec ourselves into trouble down the road. On Windows the need for this
requirement is very real indeed, and while the models differ, I can't
convince myself this will never be a problem for Linux.
>It seems to me that just as glClear() is able to jump into the proper
>context-dependant subroutine, so should glPolygonOffsetEXT() or any
>other extension function.
glClear() will be in a common dispatch table, right? And possibly even
glPolygonOffsetEXT(). What about glFunctionNotInCommonDispatchEXT() which
is supported on multiple (but not all) platforms? Pop two different cards
into a multimon system and try to run an app on both screens using the same
extension on both. Which one gets called?
>Is it the case that wglGetProcAddress on Windows returns different
>function addresses for different contexts?
Potentially yes. For example the MS software renderer supports
GL_EXT_paletted_texture. If an app uses two contexts, one in an ICD and
one in the SW renderer, and both try to use glColorTableEXT, you'll get an
implementation-specific entry point which will not work correctly for both
contexts.
-- Michael
