Roland Scheidegger wrote:
> Ian Romanick wrote:
>> I know this is a breach of protocol, but I'd like to discuss the patch
>> that I have for this before attaching it to the bug report or
>> committing it.
>> In both the client-side and the server-side g_render.c I have created
>> some template macros for generating the GLX protocol stubs. The
>> client-side version was 3,600 lines of virtually identical code. That
>> bugs me. If nothing else, it makes it difficult to determine which
>> functions exist and which ones don't. It also makes the process of
>> adding new functions tedious and error prone. I suspect that these
>> files may have been automatically generated at one point, but the
>> means for doing that are lost. After committing this fix, I intend to
>> convert almost all of the client-side g_render.c functions to use some
>> form of template.
>> I would also like to eliminate indirect_wrap.h. The only place that
>> seems to be needed is in g_render.c and vertarr.c. The templates will
>> allow it to be eliminated from g_render.c, and it should be easy
>> enough to modify vertarr.c.
>> My server-side goals are slightly more ambitious. I intend to create
>> a new header-file, dispatch_stubs.h or some such, that contains all of
>> the templated functions. Under normal circumstances, the templates
>> will generate the __glxDisp_ and __glxDispSwap_ prototypes for the
>> functions. If the file is included and GLX_GENERATE_CODE is defined,
>> the functions will be generated. A new C file, dispatch_stubs.c, will
>> be the only file to define GLX_GENERATE_CODE. It will also contain
>> the few functions that can't easilly be templatized. g_render.c
>> (server-side only), g_renderswap.c, g_disptab.h, and g_disptab_EXT.h
>> will go away. The benefit is that new functions won't need to be added
>> to a C file and a header file.
>> In the current code, a person must modify 5 source files
>> (g_disptab_EXT.c, g_disptab_EXT.h, g_render.c, g_renderswap.c, and
>> rensizetab.c) in order to add protocol for a new function. My
>> proposed changes will reduce that number to 3 (dispatch_stubs.h,
>> g_disptab_EXT.c, and rensizetab.c).
>> There is some hand editing in the patch to trim out some other stuff.
>> A couple of the client-side library changes may no apply 100%
>> cleanly. If there's a problem, please let me know.
> I usually don't comment on design decisions (because of too limited
> knowledge on the matter), but I think it's a great idea. As I've just
> figured out, it IS a pain to implement glx stuff currently, so I think
Not only is it painful to do, it's painful to even figure out what to
do. I think that's the main reason we have so much rot in the GLX code.
> it can only get better ;-). I don't quite understand yet all the
> template stuff, especially how to handle the cases when the size of the
> command depends on the parameter (I'm not a fluent speaker of cpp ;-)),
> but I'm sure it's a good idea nevertheless (even though in general I'm
> not a friend of macro overuse).
Heh...that's the one good thing about the way the code is currently
structured. The functions in g_render.c that have variable size data
(i.e., glFogfv) use a co-function, __glFogfv_size in this case, to
determine the size. The template that I have for those types of
functions, which isn't in that patch, does something like:
compsize = __ ## name ## _size(pname);
> I think the patch is not complete though, I believe you'd need to add
> some missing values (like GL_FOG_COORDINATE_SOURCE, which can get used
> in glFog[if]v if you have the FogCoord Extension to singlesize.c and
> compsize.c), at least until before everything is converted to the new
> templates. I could be wrong though (well I've added them and it didn't
> hurt ;-)).
You need to do a 'cvs update'. :) I added a *ton* of missing enums to
singlesize.c and compsize.c yesterday.