From andrea.fazzi at alcacoop.it Wed Mar 25 19:00:19 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Thu, 26 Mar 2009 00:00:19 +0100
Subject: [ruby-opengl-devel] FFI backend for ruby-opengl
Message-ID: <1238022019.6011.76.camel@ganimoide>
Dear all, dear Alain
I wonder if there might be some interest in using ruby-ffi[1] as a
backend for ruby-opengl. Actually, a prototypal FFI support for opengl
already exists: ffi-opengl[2]. The idea is to use the FFI binding as a
glue code between ruby-opengl and the opengl C libraries, delegating to
ruby-opengl the high level stuff.
I'll try to summarize some of the benefits I see in this approach:
* ruby-opengl would be multi-platform and multi-implementation
The extension would work without changes on Ruby, Rubinius, JRuby (and
on any other ruby implementation that supports FFI)
* The install process would be oversimplified
* No compilation needed anymore
* No need to install development dependencies
* ruby-opengl code would be simpler to maintain
* low-level stuff would be separated from the high-level one:
E.g.
glLightfv would be on the lower level and it would be managed by
ffi-opengl
glLight would be on the higher level and it would be managed by
ruby-opengl
I believe that there might be many benefits for the ruby-ffi project too
in joining our forces. The effort required to get a multi{platform|
implementation} and fast opengl binding will encourage the development
of some ruby-ffi features too.
Waiting for your thoughts.
Andrea
[1] - http://kenai.com/projects/ruby-ffi
[2] - http://github.com/remogatto/ffi-opengl
From jan.dvorak at kraxnet.cz Wed Mar 25 20:53:20 2009
From: jan.dvorak at kraxnet.cz (Jan Dvorak)
Date: Thu, 26 Mar 2009 01:53:20 +0100
Subject: [ruby-opengl-devel] FFI backend for ruby-opengl
In-Reply-To: <1238022019.6011.76.camel@ganimoide>
References: <1238022019.6011.76.camel@ganimoide>
Message-ID: <49CAD200.9090802@kraxnet.cz>
Hello,
> Dear all, dear Alain
>
> I wonder if there might be some interest in using ruby-ffi[1] as a
> backend for ruby-opengl. Actually, a prototypal FFI support for opengl
> already exists: ffi-opengl[2]. The idea is to use the FFI binding as a
> glue code between ruby-opengl and the opengl C libraries, delegating to
> ruby-opengl the high level stuff.
>
> I'll try to summarize some of the benefits I see in this approach:
>
> * ruby-opengl would be multi-platform and multi-implementation
>
> The extension would work without changes on Ruby, Rubinius, JRuby (and
> on any other ruby implementation that supports FFI)
>
>
Support for JRuby and other implementations would be really nice, and is
definitely something to aim for.
> * The install process would be oversimplified
>
> * No compilation needed anymore
> * No need to install development dependencies
>
>
OTOH it would add dependency on FFI (and ruby-ffi), which needs to be
compiled as well.
> * ruby-opengl code would be simpler to maintain
> * low-level stuff would be separated from the high-level one:
>
Most of the 'high-level' stuff besides function calls in ruby-opengl is
stuff like error checking, range and type tests etc., that translate to
ruby pretty much line-for-line, so i doubt it would simplify the code by
any big amount. I'm also concerned about the performance impact of
moving all this stuff into ruby code. IIRC the python opengl bindings
were doing it this way and as a result were lagging behind in
performance (i may be wrong though).
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.
best regards,
Jan
From andrea.fazzi at alcacoop.it Thu Mar 26 09:59:37 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Thu, 26 Mar 2009 14:59:37 +0100
Subject: [ruby-opengl-devel] FFI backend for ruby-opengl
In-Reply-To: <49CAD200.9090802@kraxnet.cz>
References: <1238022019.6011.76.camel@ganimoide> <49CAD200.9090802@kraxnet.cz>
Message-ID: <1238075977.5921.70.camel@ganimoide>
Il giorno gio, 26/03/2009 alle 01.53 +0100, Jan Dvorak ha scritto:
Hi Jan,
thank you for your quick answer.
> 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.
> I'm also concerned about the performance impact of
> moving all this stuff into ruby code. IIRC the python opengl bindings
> were doing it this way and as a result were lagging behind in
> performance (i may be wrong though).
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%.
> 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 :-)
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?
Thanks in advance.
Andrea
From jan.dvorak at kraxnet.cz Fri Mar 27 10:50:57 2009
From: jan.dvorak at kraxnet.cz (Jan Dvorak)
Date: Fri, 27 Mar 2009 15:50:57 +0100
Subject: [ruby-opengl-devel] FFI backend for ruby-opengl
In-Reply-To: <1238075977.5921.70.camel@ganimoide>
References: <1238022019.6011.76.camel@ganimoide> <49CAD200.9090802@kraxnet.cz>
<1238075977.5921.70.camel@ganimoide>
Message-ID: <49CCE7D1.6030500@kraxnet.cz>
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.
best regards,
Jan
From phlip2005 at gmail.com Sat Mar 28 20:09:07 2009
From: phlip2005 at gmail.com (Phlip)
Date: Sat, 28 Mar 2009 17:09:07 -0700
Subject: [ruby-opengl-devel] anisotropic.rb:188:in `glutCreateWindow': wrong
argument type String (expected Array) (TypeError)
Message-ID: <49CEBC23.2040605@gmail.com>
ruby-opengl:
I get that error simply trying to run that example. Nearly all the examples bomb
out like that.
My versions are Linux tubby 2.6.27-11-generic...
ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]
(Installed via whatever my Ubuntu 8.10 version is)
libglut3-dev - Version: 3.7-25
Aaaaand ruby-opengl-0.60.1, via gem install.
Please note that I have built ruby extensions before, including extensions that
drive OpenGL, so please don't go easy on me with the technical details!
Where should I look next?
From jan.dvorak at kraxnet.cz Sat Mar 28 22:04:12 2009
From: jan.dvorak at kraxnet.cz (Jan Dvorak)
Date: Sun, 29 Mar 2009 04:04:12 +0200
Subject: [ruby-opengl-devel] anisotropic.rb:188:in `glutCreateWindow':
wrong argument type String (expected Array) (TypeError)
In-Reply-To: <49CEBC23.2040605@gmail.com>
References: <49CEBC23.2040605@gmail.com>
Message-ID: <49CED71C.4020506@kraxnet.cz>
Hello,
> ruby-opengl:
>
> I get that error simply trying to run that example. Nearly all the
> examples bomb out like that.
>
> My versions are Linux tubby 2.6.27-11-generic...
>
> ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]
>
> (Installed via whatever my Ubuntu 8.10 version is)
>
> libglut3-dev - Version: 3.7-25
>
> Aaaaand ruby-opengl-0.60.1, via gem install.
>
> Please note that I have built ruby extensions before, including
> extensions that drive OpenGL, so please don't go easy on me with the
> technical details!
>
> Where should I look next?
Well, my best guess is that you have some conflicting installation of
previous version of the bindings, which gets loaded instead so try to
look for glut.so/glut.rb in standard ubuntu places (/usr/lib/ruby,
/var/lib/gems etc.).
Also if you have multiple versions of ruby (1.8,1.9), those are binary
incompatible so you need to compile the extensions (or install gem) for
each version separately.
regards,
Jan
From phlip2005 at gmail.com Sun Mar 29 14:41:03 2009
From: phlip2005 at gmail.com (Phlip)
Date: Sun, 29 Mar 2009 11:41:03 -0700
Subject: [ruby-opengl-devel] anisotropic.rb:188:in `glutCreateWindow':
wrong argument type String (expected Array) (TypeError)
In-Reply-To: <49CFBCD0.4080605@kraxnet.cz>
References: <49CEBC23.2040605@gmail.com> <49CED71C.4020506@kraxnet.cz>
<49CFB553.1010402@gmail.com> <49CFBCD0.4080605@kraxnet.cz>
Message-ID: <49CFC0BF.4050206@gmail.com>
[Please always configure any mailing list to respond to the mailing list!]
Sorry, just got it:
$ cat /var/log/Xorg.0.log | grep NVIDIA
(II) Module glx: vendor="NVIDIA Corporation"
(II) NVIDIA GLX Module 180.11 Wed Nov 26 11:23:16 PST 2008
(EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
To the GoogleMobile!
From andrea.fazzi at alcacoop.it Sun Mar 29 15:32:44 2009
From: andrea.fazzi at alcacoop.it (Andrea Fazzi)
Date: Sun, 29 Mar 2009 21:32:44 +0200
Subject: [ruby-opengl-devel] FFI backend for ruby-opengl
In-Reply-To: <49CCE7D1.6030500@kraxnet.cz>
References: <1238022019.6011.76.camel@ganimoide>
<49CAD200.9090802@kraxnet.cz> <1238075977.5921.70.camel@ganimoide>
<49CCE7D1.6030500@kraxnet.cz>
Message-ID: <1238355164.24937.57.camel@ganimoide>
Il giorno ven, 27/03/2009 alle 15.50 +0100, Jan Dvorak ha scritto:
> 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.
And I'm happy to hear that :-)
> 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.
I think we could begin with some preliminary measurements. In the next
days I'll submit to your attention a first benchmark.
Andrea