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

[thomas weidner]

> 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.