djtoshi182

I have eight of each gl.render, phys.world for four jit.window.

all eight renders run at the same time. Therefore, I see lags and stuttering on the four windows.

Since each screens will be assigned to each projectors, will the lagging issue be fixed if placing 8 gl.render on 1 jit.window?

There's no external video, image etc. reading from the hard drive and the patch runs with a stored alphanumeric data in the patch itself.

I don't think it's due to graphic hardware limitation.

I know it is hard to find a solution without seeing the patch, but could you tell me what's the reason that slowing down the multiple gl processing?

I have eight of each gl.render, phys.world for four jit.window.
all eight renders run at the same time. Therefore, I see lags and stuttering on the four windows.
Since each screens will be assigned to each projectors, will the lagging issue be fixed if placing 8 gl.render on 1 jit.window?
There's no external video, image etc. reading from the hard drive and the patch runs with a stored alphanumeric data in the patch itself.
I don't think it's due to graphic hardware limitation.

efficient-solution-for-running-eight-gl-render-at-once

If you do a bit of research here , you will something by MJ that's explains it pretty well.

- always use a single jit.window if you can.

- make sure , you place your window in each projector screen before you start your render.

(jit.display will give you info about each projector) 

- to use multiple rendering contex hierarchy , it's a good idea to use a jit.gl.node chain.

- if you must absolutely use multiple jit.windows , then make sure you use @shared 1 in both windows.

again place them in the correct projectors before you start the jit.gl.render.

The reason is that , this is how the GPU splits the process.

Finally, if thing are getting to big, then divide your patch into multiple instances , and share you textures over syphon or spout.

this way you will create multithreading on you CPU process.

If you do a bit of research here , you will something by MJ that's explains it pretty well. 

But in a nutshell,
-  always use a single jit.window if you can.
- make sure , you place your window in each projector screen before you start your render.
(jit.display will give you info about each projector) 
- to use multiple rendering contex hierarchy , it's a good idea to use a jit.gl.node chain.
- if you must absolutely use multiple jit.windows , then make sure you use @shared 1 in both windows.
again place them in the correct projectors before you start the jit.gl.render.
The reason is that , this is how the GPU splits the process. 

Finally, if thing are getting to big, then divide your patch into multiple instances , and share you textures over syphon or spout.
this way you will create multithreading on you CPU process.

in most cases, the only time you would want multiple gl.render / jit.window contexts is if you are using a machine with multiple discreet graphics cards, in which case you create one context per graphics card. in this case, make sure you *don't* enable @shared 1 on the windows as sharing resources across GPUs will negatively impact performance. if you're dealing with multiple display outputs from a single GPU, then you can enable sharing.

see here for an example of multiple phys.world's in a single context:

https://cycling74.com/forums/two-jit-phys-world-in-one-jit-world

see here for an example of multiple phys.world's in a single context:
https://cycling74.com/forums/two-jit-phys-world-in-one-jit-world


Efficient solution for running eight gl.render at once