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