trick stupid gmane web poster here...
I'm somehow concerned about the constants issue myself,so i think this is the right place to post my thoughts.
Oliver Markovic <entrox <at> entrox.org> writes:
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.
opengl is state based and therefore not lispy at all, it's all about side effects. Wrapping it to a lispy interface is for a higher level interface like a whole gfx engine, not for a simple opengl bindings package. you can still have (clear +color-buffer-bit+ +depth-buffer-bit+) which has much less overhead.
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.
where is the cl-opengl approach indirect? replacing constants by keywords doesn't change the way the binding work,it's only cosmetic for the end user.
[snip, agreed as solveable with keywords]
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.
no it is not. here (sbcl/amd64) a (defun clear (&rest args) ...) is ~15-20 instructions long, no extra function call. the standard keyword based version is ~120 instructions long and calls a generic function. this _IS_ a lot of overhead for such fundamental functions as opengl operations. I think the more the applications become the less are the possibilities for the compiler to optimize at compile time. think of extra effect files or external data in general where constants are simply unknown at compile time and keyword->constant dispatch has to be done at runtime. Sure, it doesn't matter for any glut demo, and also for any small game or application, but complex applications (think of a lisp version of Oblivion) it will become significant. I really don't see why we should slow down opengl applications for a small bit of "beauty". It [beauty] will be there when higher level apis are written based upon cl-opengl. My last thought: what are your points for using keywords? you seem to be really keen on not dropping them; from changing cffi to accept runtime overhead. why?
mfg thomas
PS: don't get me wrong, i really like to see that there is a opengl wrapper in active development. sorry if i hit the wrong note.