vizag08

I am a new member of the forum, and I’ve been relying on it heavily for some thesis research. Based on what I’ve read, it seems like using a hardware-render-based javascript (employing jit.gl.sketch + jit.gl.render) + jit.window should be more efficient than making use of the software-render-based jsui object. However, I have found it to be quite the opposite in my work. Basically, my goal is to use the mouse position to interactively draw/generate a smooth, flowy openGL line on the screen.

The first patch I wrote is based on jsui_splinestuff-example.pat. It uses javascript + the jsui object. I modified it so that the mouse can be used in the jsui window to draw a smooth line. When testing this patch, I noticed that MAX/MSP was using about 30% of my CPU.

The second patch I wrote is basically the same patch as the first, but it implements the Jitter listener idea in Jitter Tutorial #47 instead of jsui. It uses javascript (employing jit.gl.render + jit.gl.sketch) + jit.window. It uses the window listener to determine the mouse position so that it can be used to draw the line based on the mouse movement. When testing this patch, I saw that MAX/MSP was using up to 100% of my CPU.

Both of these patches poll the mouse position at the interval determined by the metro. Currently, up to 200 mouse positions are stored in an array for each---values that are used to draw the line. (And although I realize that this is an inefficient way of doing things, I haven’t come up with a better solution yet…suggestions welcome!) As you might notice, in the jsui patch, it runs pretty smoothly, even as the array of positions fills up. In the listener patch, however, line drawing runs fairly smoothly at the beginning, but towards the end, it lags a lot. It's horrible. =(

The consensus on the forums seems to be that using the jsui object sucks up memory. However, in writing the two patches above, I found that jsui ran much more efficiently. Both patches have virtually the same code, the main difference being that the first one uses the jsui function "ondrag" to get the mouse position, while the second patch instantiates an idle-mouse listener for the window using javascript. I am completely confused as to why the difference is so drastic. Help!

I am wanting to use javascript (employing jit.gl.sketch + jit.gl.render) + jit.window to draw a line to the screen, because I would like to be able to make the window full-screen so that it can be used for an installation piece. As far as I have read, it doesn’t seem like jsui has any sort of full-screen capabilities…is this correct? Additionally, I am wanting to composite video with the openGL, and I haven’t read about or seen any ways that I could accomplish this using jsui. Is that even possible? At any rate, using javascript (with jit.gl.sketch + jit.gl.render) + jit.window I haven’t had luck with the efficiency of the results I’ve been getting.

I know that this post is loaded with questions, but any insights to any aspects of this would be greatly appreciated!!!

P.S. I am attaching a .zip file since these two patches each rely on javascript files as well. If you have issues opening the patches, let me know, and I’ll post them in an alternate way. Thanks!

I am a new member of the forum, and I’ve been relying on it heavily for some thesis research.  Based on what I’ve read, it seems like using a hardware-render-based javascript (employing jit.gl.sketch + jit.gl.render) + jit.window should be more efficient than making use of the software-render-based jsui object.  However, I have found it to be quite the opposite in my work.  Basically, my goal is to use the mouse position to interactively draw/generate a smooth, flowy openGL line on the screen. 

The first patch I wrote is based on jsui_splinestuff-example.pat.  It uses javascript + the jsui object.  I modified it so that the mouse can be used in the jsui window to draw a smooth line.   When testing this patch, I noticed that MAX/MSP was using about 30% of my CPU.

The second patch I wrote is basically the same patch as the first, but it implements the Jitter listener idea in Jitter Tutorial #47 instead of jsui.  It uses javascript  (employing jit.gl.render + jit.gl.sketch) + jit.window.  It uses the window listener to determine the mouse position so that it can be used to draw the line based on the mouse movement.  When testing this patch, I saw that MAX/MSP was using up to 100% of my CPU.  

Both of these patches poll the mouse position at the interval determined by the metro.  Currently, up to 200 mouse positions are stored in an array for each---values that are used to draw the line.  (And although I realize that this is an inefficient way of doing things, I haven’t come up with a better solution yet…suggestions welcome!)  As you might notice, in the jsui patch, it runs pretty smoothly, even as the array of positions fills up.  In the listener patch, however, line drawing runs fairly smoothly at the beginning, but towards the end, it lags a lot.  It's horrible. =(  

The consensus on the forums seems to be that using the jsui object sucks up memory.  However, in writing the two patches above, I found that jsui ran much more efficiently.  Both patches have virtually the same code, the main difference being that the first one uses the jsui function "ondrag" to get the mouse position, while the second patch instantiates an idle-mouse listener for the window using javascript.  I am completely confused as to why the difference is so drastic.  Help!    

I am wanting to use javascript (employing jit.gl.sketch + jit.gl.render) + jit.window to draw a line to the screen, because I would like to be able to make the window full-screen so that it can be used for an installation piece.  As far as I have read, it doesn’t seem like jsui has any sort of full-screen capabilities…is this correct?  Additionally, I am wanting to composite video with the openGL, and I haven’t read about or seen any ways that I could accomplish this using jsui.  Is that even possible?  At any rate, using javascript (with jit.gl.sketch + jit.gl.render) + jit.window I haven’t had luck with the efficiency of the results I’ve been getting.    

P.S.  I am attaching a .zip file since these two patches each rely on javascript files as well.  If you have issues opening the patches, let me know, and I’ll post them in an alternate way.  Thanks!


jsui-vs-window-listener-js-jit-window

On Apr 16, 2008, at 8:49 AM, Gracie wrote:

> Both of these patches poll the mouse position at the interval 

> determined by the metro. Currently, up to 200 mouse positions are 

> stored in an array for each---values that are used to draw the 

> line. (And although I realize that this is an inefficient way of 

> doing things, I haven’t come up with a better solution 

> yet…suggestions welcome!) As you might notice, in the jsui 

> patch, it runs pretty smoothly, even as the array of positions fills 

> up. In the listener patch, however, line drawing runs fairly 

> smoothly at the beginning, but towards the end, it lags a lot. It's 

Without checking your patch in detail, it sounds like you are 

overlooking that jit.gl.sketch builds up a commandlist, so that you 

can change the camera position and it redraws everything which has 

already been drawn. So every "lineto" or other command appends to an 

internal list which probably keeps growing in your instance. You can 

either reset the command list with the reset() method each time you 

draw, use the immediate attribute, or rely on the previously cached 

commandlist rather than a JS array which you keep redrawing.

On Apr 16, 2008, at 8:49 AM, Gracie wrote:
> WHY IS JSUI WORKING BETTER?
>
> Both of these patches poll the mouse position at the interval  
> determined by the metro.  Currently, up to 200 mouse positions are  
> stored in an array for each---values that are used to draw the  
> line.  (And although I realize that this is an inefficient way of  
> doing things, I haven’t come up with a better solution  
> yet…suggestions welcome!)  As you might notice, in the jsui  
> patch, it runs pretty smoothly, even as the array of positions fills  
> up.  In the listener patch, however, line drawing runs fairly  
> smoothly at the beginning, but towards the end, it lags a lot.  It's  
> horrible. =(

Without checking your patch in detail, it sounds like you are  
overlooking that jit.gl.sketch builds up a commandlist, so that you  
can change the camera position and it redraws everything which has  
already been drawn. So every "lineto" or other command appends to an  
internal list which probably keeps growing in your instance. You can  
either reset the command list with the reset() method each time you  
draw, use the immediate attribute, or rely on the previously cached  
commandlist rather than a JS array which you keep redrawing.

Thanks so much -- your post helped immensely!! I was definitely overlooking the commandlist. It was just a matter of adding a line to the window listener code to get it to behave better by leaps and bounds. You've saved me a lot of headache. I totally appreciate it! =)

Thanks so much -- your post helped immensely!!  I was definitely overlooking the commandlist.  It was just a matter of adding a line to the window listener code to get it to behave better by leaps and bounds.  You've saved me a lot of headache.  I totally appreciate it! =)

I'm working on something similar in which I use stroke to continuously draw in a jit.gl.sketch.

after a while the patch really slows down, which I guess is due to the commandlist becoming to big. However, using reset isn't an option.

What would be the best way of keep on drawing continuously, is there an option to disable this build up of the commandlist, while still drawing?

after a while the patch really slows down, which I guess is due to the commandlist becoming to big. However, using reset isn't an option.
What would be the best way of keep on drawing continuously, is there an option to disable this build up of the commandlist, while still drawing?

jsui vs. Window Listener (js + jit.window)