[ruby-opengl-devel] FFI backend for ruby-opengl
jan.dvorak at kraxnet.cz
Fri Mar 27 10:50:57 EDT 2009
Andrea Fazzi wrote:
>> OTOH it would add dependency on FFI (and ruby-ffi), which needs to be
>> compiled as well.
> Pre-compiled gems for linux and win32 will be available soon.
We have binary gems of ruby-opengl as well. My point is that until ffi
becomes part of standard ruby, this point (that the bindings would not
need to be compiled) is moot.
> Yes, this may be true in general. But I think that this aspect should be
> investigated deeper and should be supported by measurements. My first
> *very* *naive* tests show a loss in performance of about 5-6%.
I agree, i'd be interested in seeing how fast it does full round
compared to ruby-opengl (that is, for example calling
glMultMatrixf([array]) with first converting the array to C counterpart,
calling the function, and then after return calling glGetError() ).
Another point is handling function pointers to extension functions
(which needs to be loaded via glxGetAddressProc/wglGetAddressProc). In
any case, single-digit percent drop in performance is acceptable.
>> Another thing is, the code that would need to be rewritten in ruby is
>> like 90% of whole ruby-opengl, so instead of adding ffi as backend to
>> ruby-opengl, it would be simpler to just start afresh on ffi-opengl.
> Yes, you're right. However, reading the Roadmap page on the ruby-opengl
> project site, it seems to me that there is a trend toward the
> implementation of higher level features. Thus, provided that
> performances remain acceptable, I think that delegating low level tasks
> to a ffi glue code would improve interoperability and would reduce
> installation pain. But of course this is my modest opinion :-)
As i said, is not much about delegating, as it is complete re-write.
Pretty much the only thing that would remain from ruby-opengl is
testcases and examples.
> However, the "problem" persists: there are two libraries that do almost
> the same thing (ffi-opengl doing it worse of course... ). Any idea about
> how to unify our efforts?
I will be more than happy to contribute to ffi-opengl, or if proven
feasible integrate the projects by rewriting ruby-opengl to ffi backend.
I like the idea of ruby-implementation-agnostic ogl bindings (and it has
been something that JRuby people was calling for for some time), but i
think you may be underestimating the amount of work that needs to be
done on that.
More information about the ruby-opengl-devel