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