OpenGL attrib_list support

[Andreas Hartmetz]

On Wednesday 10 July 2013 21:34:08 Alexander Monakov wrote:
> On Wed, 10 Jul 2013, Andreas Hartmetz wrote:
> > "they" is Microsoft here - those parameters only seem to occur in WGL.
> > One example is wglChoosePixelFormatARB with
> > FLOAT *pfAttribFList, an attrib_list-style parameter with floats.
> > In addition to an attrib_list-style parameter with ints, mind you, so I
> > think ~everybody will use the int version anyway.
> 
> Agreed, I'd say it's fine that your patch handles only 'int *' attrib-lists.

Okay, I couldn't stop thinking "how hard would it really be?" and it
turned out to be easier than expected, so I implemented it after all.

> > For example
> > wglGetPixelFormatAttribivARB(..., uint  nAttributes, int *piAttributes,
> > int *piValues) - the values are out-parameters, but it would still be
> > nice to interpret them correctly. The required information is now
> > available as Python data structures in the generator.
> > Outside of WGL there are similar functions with the difference that one
> > can only get one attribute value in one call, but it's the same
> > problem: The return value isn't interpreted correctly.
> 
> I see, thanks for the explanation.
> 
> 
> I've eyeballed the patch, without paying attention to {C,E,W}GL changes.
> 
> - If _AttribPairList_size function is unused now, if would be nice if your
>   patchset removed it.  Same for _AttribList_size.
> 
I've removed them after it became possible due to the other changes.

> - GLX_SAMPLES and GLX_SAMPLE_BUFFERS should be included in
> GLXFBConfigAttribs and GLXVisualAttribs, according to my understanding of
> the GLX 1.4 spec.
> 
Done, I didn't know about 1.4 (it's even a proper spec, not some
document on a random website that I was using before).

> The rest looks good to me (but this doesn't mean much).
> 
> Can you add a warning on unknown attributes?  It would be useful for
> apitrace developers, but annoying for users, so it would probably make
> sense to comment it out after merging (or silence in some other way for
> non-development builds).
> 
Done

At this point I'd like to get a final review because I don't see what
else there is to add or remove.
I was planning to let you review the patch series as is (because it 
corresponds to the mailing list discussion) and after that rearrange it
for fewer, bigger, and more atomic changes. You could then just check
that the diff is still the same afterwards. Or I can rearrange now,
whatever you prefer.

Andreas