[cl-opengl-devel] generating function bindings, extension loading

[Oliver Markovic]

On 12.11.2006, at 09:44, Bart Botta wrote:

> First suggestion is moving the function bindings to a separate
> package, and giving them lisp style names, so people like me who want
> to use them directly have supported access to them.

This is fine by me.


> Second is changing the GLenums from cffi:defcenums to defconstants.
> Advantages I can think of from doing that:

This is not. The whole point of cl-opengl was having hand-written  
bindings
that feel Lispy and not like a direct mapping to C. I do NOT want to  
write
code like (gl:clear-color (logior gl:+color-buffer-bit+ gl:+depth- 
buffer-bit+))
or having to think about how to construct a foreign array to pass to  
glLightfv.

If somebody wants to use bindings like this, Glouton[1] or kt-opengl 
[2] seem
like a better fit. They follow a different, more direct approach for  
people who
prefer that model. Writing bindings isn't exactly rocket science, so  
having more
than one way to do things is a good thing as far as I'm concerned.


>  *Easier for users to add enums from a new extension without
> modifying library code (unless cffi allows adding to an enum after it
> is defined, not sure about that)

This sounds like an easy addition to CFFI.


>  *Easier to add offsets to them, for example a loop to disable all
> lights could use (+ index gl:+light0+) instead of having to convert
> from enum and back, or store a list of the light enums or whatever.
>  *being able to add offsets also solves the problem of some values
> (light in particular) potentially having more valid values than are
> enums. (The .spec files name 8 lights, but leaves room for 4096, I'm
> pretty sure there has been hardware supporting at least 32.)

The right way (IMHO) would be to have functionality in CFFI to add  
offsets
to enums if desired, but there aren't that many places in OpenGL  
where this
would even apply.

Off the top of my head, I can name GL_LIGHTi, GL_AUXi, GL_TEXTUREi,
GL_CLIPPLANEi and GL_COLOR_ATTACHMENTi_EXT and I don't know
a single graphics card whose limits exceed those defined in the spec/ 
headers,
since a few of these are obsolete anyway thanks to programmable  
hardware.

You can see limits for most Macintosh graphics cards at
http://homepage.mac.com/arekkusu/bugs/GLInfo.html

I /do/ agree that functions like GL:LIGHT should be able to take both  
a symbolic
and a numeric identifer though, for the reasons you mentioned. But  
this can be
done without ditching CFFI enums.


>  *compatibility with other bindings (glx and cl-sdl both use +foo+
> style for enums if I remember correctly)

I neither care about GLX nor CL-SDL. If neither CLX, nor any other  
non-C library
use +foo+, why should we? Personally, I think it looks way too ugly.


>  *possibly speed. If cffi can remap values at compile time it
> probably isn't too bad, but it probably wouldn't be too hard to find
> code with a lot of enums specified at runtime.

It does remap values where possible. Here's an example from OpenMCL:

? (defun foo ()
     (gl:clear :color-buffer-bit :depth-buffer-bit))
FOO
? (disassemble 'foo)
   (TWNEI NARGS 0)
   (MFLR LOC-PC)
   (BLA .SPSAVECONTEXTVSP)
   (STWU SP -80 SP)
   (STW RZERO 8 SP)
   (LWZ ARG_Y '#<EXTERNAL-ENTRY-POINT "_glClear" (#x92E83368) /System/ 
Library/Frameworks/OpenGL.framework/OpenGL #x8476C8E> FN)
   (LWZ ARG_Z 2 ARG_Y)
   (TWEQI ARG_Z NIL)
   (VPUSH ARG_Z)
   (LI IMM0 16640)
   (STW IMM0 24 SP)
   (LWZ ARG_Z 0 VSP)
   (LA VSP 4 VSP)
   (BLA .SPPOWEROPEN-FFCALL)
   (LI ARG_Z NIL)
   (BA .SPPOPJ)

Note the LI IMM0 16640. GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT =>  
0x4100 => 16640.

But even then, the performance impact of doing so at runtime is  
neglible.


> Also, a small patch: someone in #lisp was having problems with OpenMCL
> objecting to compute-applicable-methods being called with extra
> arguments in glut/interface.lisp, which was fixed by the following
> patch to define-glut-event:
>
> diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp
> 130c130
> <                          :func ',event-func :arg-count ,(length  
> args))
> ---
>>                          :func ',event-func :arg-count ,(length  
>> arg-names))

Applied, thank you.


[1] http://common-lisp.net/project/glouton/
[2] Somewhere in http://common-lisp.net/project/cello/