Ian Romanick wrote:
> I have a question about the __GLcontextModesRec structure in glcore.h.
> Is it safe to extend that structure? I'd like to extend it to have the
> additional fields that are in __GLXFBConfigRec (from DRI's
> include/GL/glxint.h). If that were done, I could remove
> __GLXFBConfigRec entirely.
> However, I don't want to cause binary compatability problems. I did
> some checking, and I don't see any places where this structure is shared
> across module boundries (i.e., between libGL and a DRI driver, between
> libGLcore.a and libglx.a, etc.).
The ABI issue is what would concern me too. If instances of it aren't
shared among modules, you should be OK.
> I would also like to add a 'next' pointer to the start of the structure.
> One of the problems in the existing interface between the DDX driver
> and libglx.a is that an array of fixed-size structures (the visual
> configs) is passed between them. That makes it nearly impossible to
> extend the structure. Adding a 'next' pointer would help solve that.
In general, I'm a believer of implementing container data (ex: linked
list prev/next pointers) in the container data structure, and not in
the objects themselves (ala C++ STL). So, that would imply
implementing a ContextModesRectList.
But in the interest of simplicity, just adding a 'next' pointer
wouldn't be so bad, I guess.
It's your call since you're doing the work.
> The only other change I would like to make is to convert the various
> GLboolean values in the structure to single-bit bit fields. Since there
> will be at least 7 booleans in the final structure, this will save some
> memory on embedded platforms. I know that a lot of people don't like
> bit fields, so this may be contoversial. I'm not too hung up on it. :)
There are other data structures which make far more impact on memory
usage, so I guess I don't think bitfields are too important. But
again, it's your call.
> The reason I want to do this is to enable sharing a MUCH code as
> possible between the client-side GLX, server-side GLX, and the
> stand-alone interface. I don't want to end up with 3 or 4 different
> versions of glXGetFBConfigAttrib in different places that only differ by
> the datastructure they use. :) Making it so that everyone can use
> __GLcontextModesRec will enable that.
I'm in favor of that. Plus, with upcoming features like floating
point color buffers, the __GLcontextModesRec will need addition, new