glMultiDraw*Indirect

Hello!

I was just doing some early experiments with glMultiDrawElementsIndirect, and was surprised to find that it only supports a client-side java.nio.Buffer as the argument for the "command list" (the "indirect" argument in the spec), rather than also allowing a long in order to use a buffer object bound to GL_DRAW_INDIRECT_BUFFER. Conversely, I also found that glMultiDrawArraysIndirect only supports a long to use said bound buffer object, but does *not* support a client-side Buffer instead, even though the C function does support using client-side memory, just like glMultiDrawElementsIndirect does.

Is this some mere oversight, or is there some thought behind it?

Just to clarify, perhaps, what I'm finding is this:

$ javap -cp jogl-all.jar com.jogamp.opengl.GL3 | grep glMultiDraw.*Indirect
  public abstract void glMultiDrawArraysIndirect(int, long, int, int);
  public abstract void glMultiDrawElementsIndirect(int, int, java.nio.Buffer, int, int);

Whereas I would have expected this:

$ javap -cp jogl-all.jar com.jogamp.opengl.GL3 | grep glMultiDraw.*Indirect
  public abstract void glMultiDrawArraysIndirect(int, java.nio.Buffer, int, int);
  public abstract void glMultiDrawArraysIndirect(int, long, int, int);
  public abstract void glMultiDrawElementsIndirect(int, int, java.nio.Buffer, int, int);
  public abstract void glMultiDrawElementsIndirect(int, int, long, int, int);

Thank you 'Dolda2000'.

I have to check the binding / semantics of this 'indirect' call incl. unit tests.
Hope I can squeeze it in for 2.5.0.

Sounds like it was a mere oversight then, right? Does that mean I should go and file a Bugzilla report for it?

Thanks for looking at it!