please remove prototypes

[dk]

There's another issue that bothers me somewhat - the prototypes of API functions. Consider f.x. the use case for glProgramUniform3f($$$$$) - it's rather useful to call it with glProgramUniform3f($x,$y,@vec), but that's not allowed. I think that the forced syntax of glProgramUniform3f($x,$y,$vec[0],$vec[1],$vec[2]) is somewhat frustrating

[devel-chm]

That is identical to the OpenGL C API. There are also versions with a v suffix that map into exactly what you want. I didn't see any reason for implementing another method for what was already in the API. For reasons of performance/latency, it is useful to have both options. If I'm not understanding correctly, please let me know.

…

--Chris

On Mon, Jun 26, 2017 at 3:18 PM, Dmitry Karasik ***@***.***> wrote: There's another issue that bothers me somewhat - the prototypes of API functions. Consider f.x. the use case for glProgramUniform3f($$$$$) - it's rather useful to call it with ***@***.*** <https://github.com/vec>), but that's not allowed. I think that the forced syntax of glProgramUniform3f($x,$y,$vec[0],$vec[1],$vec[2]) is somewhat frustrating — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#61>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwNef7n5kJjx6n6SznZ4y7VObkr_YnQks5sIAQEgaJpZM4OFvWJ> .

[devel-chm]

I could also see supporting a glProgramUniform with no types, arg counts, or v suffix doing what you mean. There would be an unavoidable and possibly objectionable performance penalty for the generality.

[wchristian]

I agree with @dk here. Having to manually unpack arrays like that leads to Perl code that is crap. And at the end of the day we're writing Perl here, not C. Additionally the glProgramUniform3f functions supported arrays as arguments in OpenGL.pm, so this is a porting hurdle as well.

Making one's own wrapper for that in Perl just leads to lower performance.

As for the v variants: Undefined subroutine &OpenGL::Modern::glUniform2fv There's a _c version, but that's not exactly useful when one wants to pass in a perl array.

Personally i think the pure uniform functions should have a freely accepting prototype, and the prototyped ones be accessible under something like _fast if that actually gives an improvement. But if that's not easy to do with the code generation, then there should at least be legacy forms of the functions available.

[devel-chm]

Yes, the glXxx[234][fuil]v_p() have not been implemented, only the _c variants. They would have exactly the desired calling convention and usage. There should be no surprises here as these routines have been listed as TODO in the priority bindings list since 26-Jan-2017. My plan is to maintain the parallel structure with the OpenGL C API as far as fixed args and variable args. This allows an C OpenGL programmer to do the right thing with the perl bindings. The legacy forms of all the functions from OpenGL are available in OpenGL. The changes in OpenGL::Modern are being made in a minimal fashion with the intent of cleaning up the weird special case implementations in the original POGL bindings. The code generation is not the limitation, the lack of developers or users to support the implementation effort is. If you know someone who has experience in XS and is interested in helping out for the code generation, please put them in contact with me. Thanks, Chris

[dk]

If you know someone who has
experience in XS and is interested in helping out for the code generation,
please put them in contact with me.

Chris,

I can volunteer, I need though detailed requirements from you -- what is the input, what you need as the output. I wouldn't be able to help without that, because I don't have the same vision of the module you have

/dk

[dk]

I could also see supporting a glProgramUniform with no types, arg counts, or v suffix doing what you mean. There would be an unavoidable and possibly objectionable performance penalty for the generality.

I'd say "easy things easy, hard things possible" - whoever wants speed, won't use it.

[devel-chm]

BTW, I'm fine with the _p variants having the variable number of args input.

[devel-chm]

I'll collect my thoughts and write something up for the mailing list and/or wiki. The start is with the topic branch I referred to earlier.