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