mark

hi all. i'm updating some work from the dark ages of jitter. the patches that i have are very heavy on cpu usage and my current configuration gives sluggish ui performance. i have included an example of a basic jitter patch with a heavy cpu load. if you turn on jit.world and then start loading files using the umenu i see sluggish performance. as the complexity of the patch and the ui becomes more complex this becomes progesssively worse. (my performance patches have pretty extensive ui elements in bpatchers) pointers for making this more responsive would be much appreciated. i have a sneaking suspicion i'm missing something simple with the scheduler. thanks for any help with this silliness.

p.s. most recent version of max running on mac 10.10.4 . just let me know any additional information requires.

sluggish-ui-when-cpu-under-heavy-load

Can't truly test your patch as it doesn't include film files (maybe upload a version with the umenu object including the default films of max).

After looking at your patch I can see that it all runs on the CPU with standard jitter objects.

Pretty much everything there that i see there can be pushed to the GPU using jit.gl.slab (eg.brcosa , xfade etc etc..) (jit.gen default file is already a xfade by default)

I'm pretty sure that would make your patch incredibly fast compared to what it is now.

If you check the examples folder/jitter/render you can find the jit.gl.slab helper files plus some great jit.gl.pix files that recreate a lot of what you've got there.

Last thing , maybe drop jit.world. Most of what it can do is not required for your patch.

A simple jit.gl.render plus jit.window will suffice (set your jit.gl.videoplane to @transform@reset 2 to make it adapt to the screen size/ratio)

If you get stuck upload a patch and we'll get it sorted out .

Can't truly test your patch as it doesn't include film files (maybe upload a version with the umenu object including the default films of max).
After looking at your patch I can see that it all runs on the CPU with standard jitter objects.

Pretty much everything there that i see there can be pushed to the GPU using jit.gl.slab (eg.brcosa , xfade etc etc..) (jit.gen default file is already a xfade by default)
I'm pretty sure that would make your patch incredibly fast compared to what it is now.

If you check the examples folder/jitter/render you can find the jit.gl.slab helper files plus some great jit.gl.pix files that recreate a lot of what you've got there.
Last thing , maybe drop jit.world. Most of what it can do is not required for your patch. 

A simple jit.gl.render plus jit.window will suffice (set your jit.gl.videoplane to @transform@reset 2 to make it adapt to the screen size/ratio)
If you get stuck upload a patch and we'll get it sorted out .


thanks for looking at this. the files are simple 768x432 photojpeg movies to put a load on the signal chain.

i realize that this can all be ported to shaders, however this is simply a configuration to induce the problem. there are cases where i wish to rely on matrix processing and the cpu to do this work.

any other ideas for helping the ui to be more responsive while doing this much cpu crunching in jitter?

thanks for looking at this. the files are simple 768x432 photojpeg movies to put a load on the signal chain. 

Delete the jit.p.window ( win a few frames )

If your goal is to overload the cpu then its achieved. Downside is more unresponsive ui.

Pushing things to the gpu and using a slower qmetro could work, or just slow qmetro down as the system doesn't keep up anyway.

Its not clear what your aim is.
Delete the jit.p.window ( win a few frames )
If your goal is to overload the cpu then its achieved. Downside is more unresponsive ui.
Pushing things to the gpu and using a slower qmetro could work, or just slow qmetro down as the system doesn't keep up anyway.


i'm trying to determine if it is possible to have a responsive ui when the cpu is taking a big hit. i have patches where a significant amount of processing will be happening on both the cpu and gpu and maintaining responsiveness would be very useful for live performance.

Ui is drawn on the cpu. So you have a problem if you want to bottleneck the cpu and have a responsive ui.

sluggish ui when cpu under heavy load.