OpenGL attrib_list support

Andreas Hartmetz ahartmetz at gmail.com
Wed Jul 3 01:54:50 PDT 2013


Hello list,

I've been trying to implement attrib_list support for a few days now and I've 
run out of approaches that aren't ugly or intrusive.
(attrib_list is an array of ints interpreted as key-value pairs where the key 
is an enum value and the value's interpreted type depends on the key; it is 
usually int, enum, or bitfield.)
First I started with a basic type similar to Enum / EnumSig. That turned out 
to involve way too much code to be written in all corners of the code 
generation machinery.

Then I found EnumPolymorphic which is Python-only (no additions in 
trace_model.hpp required), and also realized that it's OK to interpret the 
data only before serializing, not after, and probably even OK to write an 
array where not every element contains the same type. But EnumPolymorphic 
requires a simple C expression to give the interpretation of each key and 
value. This causes a problem: The interpretation should always be the same for 
a key, which doesn't map easily to the switch-case generated code (would need 
access to the array index, and to find an unused value for the "this is a key" 
case). Of course one could insert code to turn the switch into a no-op, insert 
an if statement (key or value), and start a second switch for the value.... 
very very ugly and still needs the array index.

Another problem is: The interpretation of a value depends on the key, so there 
is the need to access the previous attrib_list element (the key). I don't see 
how to do that in the current framework. Currently, array elements know 
nothing about each other or about the array.

Does anyone have any ideas how to handle attrib_list sanely? That would be 
great.

Cheers,
Andreas Hartmetz


More information about the apitrace mailing list