[Mesa-dev] [PATCH 12/14] mesa/vbo: Move src/mesa/vbo/vbo_exec_array.c -> src/mesa/main/draw.c

[Mathias Fröhlich]

Hi Brian,

On Tuesday, 30 October 2018 13:06:50 CET Brian Paul wrote:
> The series looks great, Mathias.
> 
> Reviewed-by: Brian Paul <brianp at vmware.com>

Thanks for that one!

> > @@ -2072,7 +2073,7 @@ vbo_initialize_exec_dispatch(const struct gl_context *ctx,
> >   void GLAPIENTRY
> >   _mesa_DrawArrays(GLenum mode, GLint first, GLsizei count)
> >   {
> > -   vbo_exec_DrawArrays(mode, first, count);
> > +   _mesa_exec_DrawArrays(mode, first, count);
> >   }
> 
> It would be nice to avoid this pattern of simply calling another 
> function like this.
> 
> The complication, though, is that the _mesa_exec_Draw*() functions get 
> put into the dispatch table, but the _mesa_Draw*() functions are 
> decorated with GLAPIENTRY since they're Windows dll export functions.
> 
> We'd have to decorate some entries in the dispatch table with 
> GLAPIENTRY, but that could involve some messy python script work.

Looking at that, at least both functions _mesa_DrawArrays and
vbo_exec_DrawArrays/_mesa_exec_DrawArrays have the GLAPIENTRY.
It's probably the pattern for all of these.

May be I don't quite understand, but to me that looks just like a naming
issue that got solved at one point by calling one function from an other?
And don't all dispatch table functions have the GLAPIENTRY as well as
the GLvertexformat functions?

> What do you think?
Now confused ...

I think it's just a level of indirection that was introduced for a reason
that went away at one point in the past. May be the reason was just the naming
that the vbo module used to have these vbo_ prefixes that are changed by this
patch?

... I still suspect that I have missed something obvious from your question - sorry.

best

Mathias