porting js ogl to c


    Aug 23 2006 | 3:33 pm
    Hi list,
    I'm prototyping a user interface in JS, using Jitter gl objects to draw to a named jit.pwindow in a patcher together with a JitterListener to get the mouse callback.
    Now I'm thinking about porting the whole thing to C but since I'm not a very experienced C programmer and the JS code is about 3k lines I feel I could use some advise. I've never compiled a Jitter or UI external before (only MSP) and I'm just curious to know how I should approach this. I know you can instantiate Jitter objects in C just as you can in JS, so I suspect no problems there.
    What about JitterListener, is it available too? Or, even better, can I somehow merge the render context from jit.pwindow with the rest of the code to make it one external?
    I need hardware accelerated OpenGL, and Pluggo compatibility is also a big pre.
    Is there anyone experienced with this who wants to share some insights?
    cheers, -thijs

    • Aug 23 2006 | 5:24 pm
      On 8/23/06, Thijs Koerselman wrote: > Now I'm thinking about porting the whole thing to C but since I'm not a very > experienced C programmer and the JS code is about 3k lines I feel I could > use some advise. I've never compiled a Jitter or UI external before (only > MSP) and I'm just curious to know how I should approach this. I know you can > instantiate Jitter objects in C just as you can in JS, so I suspect no > problems there. I think that the first question to ask is exactly what you plan to gain from switching to C from Javascript. If it works, there's no real need to fix it. If performance is an issue, then it would be worth trying to build an external. If you're just trying to reduce the wiring complexity, it might be worth trying to put your functionality into a patcher.
      > Is there anyone experienced with this who wants to share some insights? You mention that you've never compiled a Jitter external before -- Instead of starting with a 3000-line monster, why not start building some simple externals that have a bit of the functionality of your main project? It can take time to get used to Jitter's framework, features, and conventions. It took me ages to figure out how to specify the number of inputs, let alone to figure out what bip, fip, fop, and bop were referring to. The challenge of learning the language (C/C++) can greatly compound the problem of learning the API.
      Some recommendations are to output a matrix with a constant size and color, draw some simple gradients and shapes, handle input, do some basic OpenGL, et cetera. Once you've got the individual basics done, you'll have enough experience to put together your final project. Furthermore, since each work unit along the way will be small and (relatively) simple, the more experienced folks on the list will be able to give you targetted advice on how to achieve your goals.
      Hope this helps.
    • Aug 23 2006 | 6:46 pm
      On 8/23/06, Thomas Johnson wrote: > > > I think that the first question to ask is exactly what you plan to > gain from switching to C from Javascript. If it works, there's no real > need to fix it. If performance is an issue, then it would be worth > trying to build an external. If you're just trying to reduce the > wiring complexity, it might be worth trying to put your functionality > into a patcher.
      Wiring? I don't understand what you mean, it's JS. But yes performance is the issue. The UI is a sequencer and it's going to be a really fundamental thing to me. I need it to be as efficient and snappy as can be. Right now one instance can use up to 20% of my cpu (while doing a lot of editing), and that's too much, because I want to use more than one. The opengl part is already really optimized, so I suspect the cpu load comes from the data handling of the notes and cc curves.
      features, and conventions. It took me ages to figure out how to > specify the number of inputs, let alone to figure out what bip, fip, > fop, and bop were referring to. The challenge of learning the language > (C/C++) can greatly compound the problem of learning the API.
      Well I'm not that much of a beginner either. The Jitter API won't be a lot more difficult than the Max/MSP one, but you're right about starting with some small testprojects. I just like to know in advance if it's possible or not, so I'm not waisting loads of time trying to implement something that's not going to work in the end.
      I'll just start with rendering to a jit.pwindow like I do in JS, but if anyone knows a way to write opengl interfaces with an integrated rendering context I'd love to hear about it.
      best, -thijs
    • Aug 23 2006 | 8:00 pm
      On Aug 23, 2006, at 11:46 AM, Thijs Koerselman wrote:
      > I'll just start with rendering to a jit.pwindow like I do in JS, > but if anyone knows a way to write opengl interfaces with an > integrated rendering context I'd love to hear about it.
      You'd have to write everything yourself from scratch. Couldn't use Jitter. Fundamentally not that tough, but requires a decent amount of work (I'd plan on a week or two of focused work to get that all ironed out).
      -Joshua
    • Aug 23 2006 | 8:10 pm
      Couldn't you just make something similar to jit.gl.handle? Basically, use the JIT_OB3D_DOES_UI flag for your ob3d object and process the input to update how your object draws?
      wes
      On 8/23/06, Joshua Kit Clayton wrote: > > On Aug 23, 2006, at 11:46 AM, Thijs Koerselman wrote: > > > I'll just start with rendering to a jit.pwindow like I do in JS, > > but if anyone knows a way to write opengl interfaces with an > > integrated rendering context I'd love to hear about it. > > You'd have to write everything yourself from scratch. Couldn't use > Jitter. Fundamentally not that tough, but requires a decent amount of > work (I'd plan on a week or two of focused work to get that all > ironed out). > > -Joshua > >
    • Aug 23 2006 | 8:16 pm
      On Aug 23, 2006, at 1:10 PM, Wesley Smith wrote:
      > Couldn't you just make something similar to jit.gl.handle? Basically, > use the JIT_OB3D_DOES_UI flag for your ob3d object and process the > input to update how your object draws?
      Yes, this is possible, but it doesn't put it all into one UI object (requires separate jit.gl.render, jit.pwindow, and jit.gl.whateveritis).
      -Joshua
    • Aug 23 2006 | 8:26 pm
      On 8/23/06, Joshua Kit Clayton wrote: > > > > You'd have to write everything yourself from scratch. Couldn't use > Jitter. Fundamentally not that tough, but requires a decent amount of > work (I'd plan on a week or two of focused work to get that all > ironed out).
      With my knowledge of C I think it would take me at least twice that time. The only thing I'm really good in as it comes to C is making max crash, so I think I better stick to Jitter objects for now. The performance increase will probably still be a lot (and enough) in comparison to js. My first C reference book is on the way so maybe there's still hope:-) Thanks for letting me know.
      best, -thijs
    • Aug 23 2006 | 8:40 pm
      Ok, so if you need jit.gl.rendere and jit.window as well, you can just pipe the data from those guys into your custom gl object and just define methods or attributes that take parameters from 'em. For example you would take the mouse data from jit.window and pipe it into your object.
      wes
      On 8/23/06, Thijs Koerselman wrote: > > > On 8/23/06, Joshua Kit Clayton wrote: > > > > > > You'd have to write everything yourself from scratch. Couldn't use > > Jitter. Fundamentally not that tough, but requires a decent amount of > > work (I'd plan on a week or two of focused work to get that all > > ironed out). > > > With my knowledge of C I think it would take me at least twice that time. > The only thing I'm really good in as it comes to C is making max crash, so I > think I better stick to Jitter objects for now. The performance increase > will probably still be a lot (and enough) in comparison to js. My first C > reference book is on the way so maybe there's still hope:-) Thanks for > letting me know. > > best, -thijs > > > > > > > > >
    • Aug 23 2006 | 8:57 pm
      On 8/23/06, Wesley Smith wrote: > > Ok, so if you need jit.gl.rendere and jit.window as well, you can just > pipe the data from those guys into your custom gl object and just > define methods or attributes that take parameters from 'em. For > example you would take the mouse data from jit.window and pipe it into > your object.
      Sounds like a good plan. I don't really care all that much about a separate pwindow, as long at it's a lot faster than my JS code. I guess there is no JitterListener equivalent in C for getting mouse callback?
      -thijs
    • Aug 23 2006 | 9:03 pm
      On Aug 23, 2006, at 1:57 PM, Thijs Koerselman wrote:
      > Sounds like a good plan. I don't really care all that much about a > separate pwindow, as long at it's a lot faster than my JS code. I > guess there is no JitterListener equivalent in C for getting mouse > callback?
      There is. You just use object_attach(). Check out the jit.notify example for now, and I hope to send a better example of this and the ob3d_ui approach later.
      -Joshua
    • Aug 23 2006 | 9:27 pm
      On 8/23/06, Joshua Kit Clayton wrote:
      > > There is. You just use object_attach(). Check out the jit.notify > example for now, and I hope to send a better example of this and the > ob3d_ui approach later.
      Ah cool. I'm still stuck with windows though, but I'll have a look at the 1.6 sdk examples. Really nice work btw, the new jitter sdk. It'll help me a lot.
      -thijs