pseudostereo

The frame rates on my current project have gotten worse and worse as the patcher has grown, and I finally tracked the problem down to jit.playlist. It seems that the more movies you load into a jit.playlist, the more negative impact it has on the frame rate.

I've attached an example; a jit.playlist with a single movie plays back at almost double the rate of a jit.playlist with 30 entries. The movie in the example is only 320x240, so it shouldn't be taxing the gpu at all, still the frame rate drops from about 60fps to about 30fps.

And the problem gets much worse when the movies are larger - I was getting rates of < 10fps with a bunch of HD movies, even though they play full speed normally.

I love jit.playlist, but I'll probably have to rebuild the project without it if I can't sort this out.

Meanwhile, it would be great if jit.playlist could report some more useful information about each clip. The 'getcontent' message outputs a dictionary of the clips, but it's currently pretty useless: it always reports dim as 1 1 no matter what the movie dimensions actually are, it doesn't report the duration of the movie, and it always reports time and time_secs as 0.

One other anomaly : Starting the movie sends 'start 1' out the middle outlet, but stopping the movie inexplicably sends another 'start 1' before it sends the expected 'done 1'.

The frame rates on my current project have gotten worse and worse as the patcher has grown, and I finally tracked the problem down to jit.playlist. It seems that the more movies you load into a  jit.playlist, the more negative impact it has on the frame rate. 

I've attached an example; a jit.playlist with a single movie plays back at almost double the rate of a jit.playlist with 30 entries. The movie in the example is only 320x240, so it shouldn't be taxing the gpu at all, still the frame rate drops from about 60fps to about 30fps. 

jit-playlist-slowdown

hi PSEUDOSTEREO, thanks for your feedback. i've captured all your comments in a ticket for improvements to jit.playlist.

i was experiencing performance problems with jit.playlist and came across this post. i think i pinned down some of the issues -- it does not have to do with the number of clips in the list, but with drawing the UI. if you move the playlist in a subpatch and close it the FPS goes back up. it somewhat defeats the purpose of using it in the first place but hopefully at least it helps identify the issues. here is a modification of the OP patch

    "version" : "Version 8.1.2 (1bd89fe) (64-bit mac)",

    "osversion" : "Mac OS X Version 10.15.3 (Build 19D76) x86_64",

    "scheduler_in_audio_interrupt" : "off",

    "audio_drivername" : "Core Audio",

    "machine_id" : "75382c39f4e0ff73e25881b58e484819",

    "refreshrate" : 33.333332061767578,

        "Jitter Recipes" : "0.1.1",

        "Node For Max" : "1.3.2",

        "Video and Graphics" : "7.2.0",

i was experiencing performance problems with jit.playlist and came across this post. i think i pinned down some of the issues -- it does not have to do with the number of clips in the list, but with drawing the UI. if you move the playlist in a subpatch and close it the FPS goes back up. it somewhat defeats the purpose of using it in the first place but hopefully at least it helps identify the issues.  here is a modification of the OP patch

{
	"version" : "Version 8.1.2 (1bd89fe) (64-bit mac)",
	"platform" : "mac",
	"arch" : "x64",
	"osversion" : "Mac OS X Version 10.15.3 (Build 19D76) x86_64",
	"samplerate" : 44100,
	"iovs" : 512,
	"sigvs" : 64,
	"scheduler_in_audio_interrupt" : "off",
	"audio_drivername" : "Core Audio",
	"audio_driver_subname" : "",
	"license" : "permanent full",
	"machine_id" : "75382c39f4e0ff73e25881b58e484819",
	"eventinterval" : 2,
	"schedinterval" : 1.0,
	"overdrive" : "off",
	"pollthrottle" : 40,
	"queuethrottle" : 100,
	"sysqelemthrottle" : 1000,
	"refreshrate" : 33.333332061767578,
	"schedslop" : 25.0,
	"eventprobing" : 0,
	"mixerparallel" : "off",
	"mixercrossfade" : 0,
	"mixerlatency" : 30.0,
	"mixerramptime" : 10.0,
	"videoengine" : "avf",
	"glengine" : "gl2",
	"packages" : 	{
		"BEAP" : "1.0.2",
		"Gibberwocky" : "0.2.0",
		"gl3" : "0.1.2",
		"hap" : "1.0.6",
		"ISF" : "1.0.2",
		"jit.mo" : "1.1.2",
		"Jitter Recipes" : "0.1.1",
		"max-mxj" : "7.2.5",
		"Mira" : "1.2.1",
		"ml.lib" : "1.0.3",
		"ml.star" : "1.2.0",
		"Node For Max" : "1.3.2",
		"Syphon" : "1.0.6",
		"VIDDLL" : "1.2.1",
		"Video and Graphics" : "7.2.0",
		"Vizzie" : "2.0.3",
		"VR" : "1.0.1"
	}

a bit late to reply but wanted to say thanks Liubomir for the patch. I can see the performance impact and it has to do with the drawing requirements of jit.playlist when it is playing a clip. We are currently looking at playlist improvements for the next update, and I'll see if drawing performance improvements fall within that scope.

jit.playlist slowdown