On 9 April 2016 at 01:21, Marek Olšák <mar...@gmail.com> wrote: > On Fri, Apr 1, 2016 at 2:13 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 16 March 2016 at 10:40, Marek Olšák <mar...@gmail.com> wrote: >> >>> "offset_after" isn't nasty. :) Yeah, I was inspired by other APIs I >>> had seen. The sizes make even more sense when they are function >>> parameters, because the caller can just do: >>> (sizeof(in), &in, sizeof(out), &out) >>> >> A nice list of arguments: >> - If the majority of people like offset_after, the question "Why >> barely any projects use it (from a quick search) ?" comes to mind. >> - I wasn't the only one advocating for versioned interfaces ;-) >> - They will just work in an identical way and the code will be less. >> - Regardless of how ugly/nasty/etc, mesa uses versioned interfaces >> throughout. "Consistency is the key" a wise man have said once. >> - The interfaces using explicit size argument, that I'm aware of, are >> not designed with extensibility in mind. > > Updated branch with your suggestions applied: > https://cgit.freedesktop.org/~mareko/mesa/log/?h=interop > Thank you very much.
Hopefully, some of the arguments made sense, as opposed to doing this just to make me happy (read 'shut me up'). From a quick look: - Food for thought: An feeling about "can we get away without including glx.h and EGL.h in mesa_glinterop.h" kicks in. As-is specifics from one winsys are leaked while building the other and vice-versa. I'm wondering about incomplete/forward declaration of the needed types, although that might be a bad idea ? - The struct_version checks seem off -> they are == 0, while they should be < 1. The idea is for newer versions to be backward compatible, correct ? -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
