]> git.notmuchmail.org Git - apitrace/commit
replay: Support applications mixing glCreateProgramObjectARB and glUseProgram
authorCarl Worth <cworth@cworth.org>
Tue, 28 Aug 2012 18:45:52 +0000 (11:45 -0700)
committerCarl Worth <cworth@cworth.org>
Sat, 16 Feb 2013 02:24:31 +0000 (18:24 -0800)
commit37007777c37b1d28abfe1ac07901d1e13e12b113
treedec8764c211cbc29a9d82368d272663029c0d6f6
parent75cbb8c52730680271ce5fe939ff6607ab004eaa
replay: Support applications mixing glCreateProgramObjectARB and glUseProgram

As is known to happen with OpenGL, there are many more than one ways
to do the same thing. In this case, one can create a program
(glCreateProgram) or a program object (glCreateProgramObjectARB) along
with many similar pairs of functions.

In fact, a single application might even mix these two approaches,
(for example, calling glCreateProgramObjectARB and then calling
glUseProgram rather than glUseProgramObjectARB).

Historically, glretrace could fail with such mixed usage. The calls
into the ObjectARB function would go through _handleARB_map while the
other calls would go through _program_map, so after mixed calls the
desired object would not be found in the referenced map.

Making mixed usage work requires merging both _program_map and
_shader_map together with _handleARB map. This is correct for any
OpenGL implementation which supports the GL_ARB_shader_objects
extension, since there is no way to implement this extension correctly
without having shaders and programs in the same namespace.

However, we carefully maintain separate _shader_map and _program_map
for an OpenGL implementation not supporting GL_ARB_shader_objects. In
this case, it's not possible for an application to mix usage (since
none of the ObjectARB functions are guaranteed to exist). And it's
also possible for the implementation to provide separate namespaces
for shaders and programs, so they each need their own map.
retrace/glretrace.hpp
retrace/glretrace_main.cpp
retrace/retrace.py