Hi Brian,
On Tuesday, 30 October 2018 13:06:50 CET Brian Paul wrote:
> The series looks great, Mathias.
>
> Reviewed-by: Brian Paul <bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
