jsui vs jit.pwindow listener


    Aug 02 2006 | 7:55 pm
    I'm using jsui for a pretty complex sequencing interface and I'm getting a little worried about the cpu load. I just remembered about js jitter listeners, and before I change my code around I'd like to know if the jit.pwindow + listener will improve things or not. I need both pattr and opengl support, so mxj and lcd are no options afaik.
    -thijs

    • Aug 04 2006 | 5:48 pm
      i've done something along that line, using custom-coded "buttons" and listeners. it's fairly straightforward, i'll release it eventually when i get it cleaned up but in the meantime if you have any specific questions i may be able to help.
      one thing I found useful was using Apple's "OpenGL Profiler" tool (part of Developer's tools) to look at patches when using jsui - I found a lot of costly glclear() function calls, and wound up being a lot more careful about when and what I drew to the screen. (The GL profiler gives you a complete list of all GL calls that are going on, and an idea of how much GPU they are eating up.)
      Hope that was a little helpful.
      best evan
      On Aug 2, 2006, at 8:55 PM, Thijs Koerselman wrote:
      > I'm using jsui for a pretty complex sequencing interface and I'm > getting a little worried about the cpu load. I just remembered > about js jitter listeners, and before I change my code around I'd > like to know if the jit.pwindow + listener will improve things or > not. I need both pattr and opengl support, so mxj and lcd are no > options afaik. > > -thijs
    • Aug 04 2006 | 7:00 pm
      Hi Evan, Thanks for the reply. Unfortunately I'm using windows:-( Do you have any idea if drawing to jit.pwindow is more efficient? I can imagine it is because it can use hardware ogl acceleration as opposed to jsui, which cannot (right?).
      I'm not sure what the bottle neck is in my jsui, it might just be the javascript calculations, but I really doubt it. I'm pretty sure the opengl calls are efficient though. Especially using ondrag mouse functions are really boosting the cpu usage, but that's something I've experienced with all rather complex jui interfaces I've come across. I've used Task objects to limit the redrawing interval, but that makes the UI a lot less responsive if I want to cut the cpu drain by a decent amount.
      best, -thijs
      On 8/4/06, evan.raskob [lists] wrote: > > i've done something along that line, using custom-coded "buttons" and > listeners. it's fairly straightforward, i'll release it eventually > when i get it cleaned up but in the meantime if you have any specific > questions i may be able to help. > > one thing I found useful was using Apple's "OpenGL Profiler" tool > (part of Developer's tools) to look at patches when using jsui - I > found a lot of costly glclear() function calls, and wound up being a > lot more careful about when and what I drew to the screen. (The GL > profiler gives you a complete list of all GL calls that are going on, > and an idea of how much GPU they are eating up.) > > Hope that was a little helpful. > > > best > evan > > >
    • Jan 05 2007 | 4:19 am
      "i've done something along that line, using custom-coded "buttons" and listeners. it's fairly straightforward, i'll release it eventually when i get it cleaned up but in the meantime if you have any specific questions i may be able to help."
      Could evan or anyone else post an example of a js.jit.pwindow interface widget which utilizes openGL? I'm beginning to feel its impossible because all the examples are in jit.windows. (I'm almost sure its not worth all this trouble) I'm having tons of trouble working out the logistics of offscreen rendering, recognition of the rendering context on load, reinstantiating js.jit objects etc.
      an example would be very very helpful.
      [check] examples folder [check] documentation [check] tutorials maxobjects not loading
    • Jan 05 2007 | 9:12 am
      do you mean the jsui classes, lfo.jsui?
      if you wanted to do it with jit.pwindow, here's some (rough) code that uses jit.gl.sketch to create buttons, a listener to catch mouse events from the jit.pwindow, and then do some simple dragging and coloring of the drawn objects. it's not great, i threw it togetehr from another project this morning, but maybe it'll be a slight help.
      cheers evan
      On Jan 5, 2007, at 4:19 AM, Matthew Aidekman wrote:
      > > "i've done something along that line, using custom-coded "buttons" and > listeners. it's fairly straightforward, i'll release it eventually > when i get it cleaned up but in the meantime if you have any specific > questions i may be able to help." > > > Could evan or anyone else post an example of a js.jit.pwindow > interface widget which utilizes openGL? I'm beginning to feel its > impossible because all the examples are in jit.windows. (I'm almost > sure its not worth all this trouble) I'm having tons of trouble > working out the logistics of offscreen rendering, recognition of > the rendering context on load, reinstantiating js.jit objects etc. > > > an example would be very very helpful. > > > > > [check] examples folder > [check] documentation > [check] tutorials > maxobjects not loading
    • Jan 05 2007 | 9:30 pm
    • Jan 06 2007 | 1:40 pm
      Thanks for the reply, thjis.
      you bring up a good point for dragging. It seems the solution would be a defered repetitive Task rather than calling draw directly from the callback.
      I ended up solving many of my problems by putting alot of the jit.gl declarations into a loadbang function instead of global code.
      one thing remains which, in the interest of organization, I'll post a separate (and hopefully last) topic for.
    • Jan 07 2007 | 12:08 pm
      On Jan 6, 2007, at 1:40 PM, matthew aidekman wrote:
      > > I ended up solving many of my problems by putting alot of the > jit.gl declarations into a loadbang function instead of global code.
      I don't put anything in loadbang anymore except for basic variable initializations. Then, in the end of loadbang, I always call "init ()" which actually does the initialization. I've been doing this because loadbang is automatic and happens (for all intents and purposes) at the same time as all other loadbangs in the patch, so things are a bit fuzzy as to what is actually being initialized or is ready at the time. Especially in a patch where your jit.gl.render is outside the js code.
      I posted an example awhile back that works for me on multiple machines:
      https://cycling74.com/forums/index.php? t=msg&rid=0&S=d720ea99f76dd2d3dd43ec5e94aebb72&th=22172&goto=81781
      I've found that loading textures and swapping matrix contents (calling matrixcalc) in short intervals is bad. It seems that the js can't catch up to C, or messages are lost along the way, and things don't happen that you expect to. On my now-stolen) G4 laptop, this was the case.
      best evan