1

I'm trying to create OpenGL bindings for Node. Because of the sheer size of the OpenGL API, doing this manually is impractical, so I turned to Khronos' OpenGL registry.

The files that are provided are easy enough to parse, but there seems to be an important piece missing, and that's how to compute the size of non-trivial parameter buffers.

Here's an example of a function definition that needs such an output buffer. Notice the COMPSIZE() expression:

GetTextureImageEXT(texture, target, level, format, type, pixels)
    return      void
    param       texture     Texture in value
    param       target      TextureTarget in value
    param       level       CheckedInt32 in value
    param       format      PixelFormat in value
    param       type        PixelType in value
    param       pixels      Void out array [COMPSIZE(target/level/format/type)]
    category    EXT_direct_state_access
    dlflags     notlistable
    glxflags    ignore ### client-handcode server-handcode
    extension   soft WINSOFT
    glfflags    capture-execute capture-handcode decode-handcode pixel-pack

This example illustrates the problem well. It seems clear that the "pixels" parameter needs an output buffer whose size depends on the target, level, format and type parameters. But how or where can I find the actual formula to compute that size?

The only piece of related information I could find online was a C source file called compsize.c that apparently belongs to the Apple implementation of OpenGL.

Can anyone help me find the hard data on this?

genpfault
  • 51,148
  • 11
  • 85
  • 139
JPNotADragon
  • 2,050
  • 2
  • 25
  • 31
  • Looking at the gl.spec file will make your brain explode. What `COMPSIZE` is shorthand notation for is "find the associated values the parameters listed" (e.g., for GetTexImageEXT, _format_ could be `GL_RGBA8`, and so you'd need to derive four bytes for that). You'd be better off starting with an open-source implementation (e.g., [Mesa](http://mesa3d.org), or the [OpenGL Sample Implementation](http://oss.sgi.com)), and pulling this code from there. Or, you might consider using WebGL if it meets your needs - it's already available in Node. – radical7 Mar 15 '13 at 22:03
  • @radical7: That explains why I had so much trouble concentrating today, having looked at the specs yesterday night :-) – JPNotADragon Mar 15 '13 at 22:10
  • @radical7: So you are basically saying that information is not available in parseable form, and must be obtained manually on a per-function and per-platform basis? I used the GLES2 Node bindings as the starting point for this project. They leave the task of providing output buffers to the caller, which I may end up having to do too, however I had hoped for a way to make this more fun for programmers... WebGL won't cut it for me - it's gotta be OpenGL. – JPNotADragon Mar 15 '13 at 22:22
  • @Hans-PeterGygax: The information is based on the stated parameters: the particular texture type, the mipmap level being queried, the [given pixel transfer format, and the given pixel transfer type](http://www.opengl.org/wiki/Pixel_Transfer#Pixel_transfer_arguments). Doing the full computation for all possible cases is *not* a trivial undertaking. Note that it also depends on [the packing parameters](http://www.opengl.org/wiki/Pixel_Transfer#Pixel_transfer_parameters). How to do this computation is defined by the spec, but it's not a simple algorithm in the slightest. – Nicol Bolas Mar 16 '13 at 00:57
  • @Nicol: GetTextureImageEXT was just an illustrative example I picked, I was actually hoping for an even more generalized and automated solution. But when you say "defined by the spec", I take it you mean "defined in text", not in a machine-parseable form. – JPNotADragon Mar 16 '13 at 09:45

1 Answers1

0

I'm going to answer my own question here.

It is my conclusion that what I was trying to achieve just doesn't fit the way OpenGL is meant to work; the computation I wanted to automate simply depends on too many factors to be done that way.

Just to clarify: what I intend to do is providing OpenGL bindings for Node (the command-line JavaScript interpreter based on Google's V8 virtual machine). As some OpenGL (or extension) calls return significant amounts of data and/or that data can have a non-trivial memory layout, I was hoping to help programmers by allocating the required output buffers through auto-generated code based on Khronos' parseable specification files, the same that are already used by projects such as GLEW to generate their extended C bindings.

Based on the answers I received (thank you all!), that idea was naive - and the intent not as helpful as I thought, because, thinking about it, simply having a buffer of the right size might avoid access violations, but does not help a programmer use the information he obtained. In the end, he still needs to know the exact memory layout anyway, so allocating the buffer won't be an issue for him (well, in theory at least).

In light of all this, computing output buffer sizes, as well as handling their content, is better left to the next-higher software layer. And because no-one to my knowledge uses the whole of the OpenGL API in the same piece of software, there is no actual need for a single library to handle all possible output buffer allocations.

Thanks to all who responded!

JPNotADragon
  • 2,050
  • 2
  • 25
  • 31