DiGiTaLFX

I have recently started learning Max/Jitter and thought a nice little project to get to grips with everything would be to make my own video player. I started off just outputting a jit.qt.movie directly to a jit.window, listened for a few keys to control it and allowed the video to go fullscreen. Everything was great. Then I moved on to outputting the jit.qt.movie to a jit.gl.videoplane with all the necessary adjustments. Again great! However I have now implemented a jit.gl.slab before the videoplane and now when I play video fullscreen I probably get a framerate of about 2 or 3fps. After a bit of experimenting I found out that this was only occuring when fsmenubar was set to 0 on the jit.window. However tabbing out so it is still fullscreen but has a window on top of it results in normal playback once more.

Any ideas? I'm running a MacBook Pro with 9400M graphics on Snow Leopard.

fullscreen-slab-stuttering

can you please provide a simple patch that demonstrates what you are talking about, as well as your OS and max 5 versions?

bizarre. thanks for the report.
can you please provide a simple patch that demonstrates what you are talking about, as well as your OS and max 5 versions?

Hi I'm on OS X 10.6.1 using Max 5.0.8. The test videos I have been using are 640x360 h.264 files in an mpeg4 container (exported from iMovie I believe but I didn't create them)

I have attached a simple patch. Read a file in, then press 'f' for fullscreen. Now press 's' to enable the opengl slab and on my system at least, the video starts to stutter. 's' again disables the slab.

I have tried the attached patch with the erasing being triggered directly by the qmetro rather than by the output of the matrix from jit.qt.movie, but there's no difference.

edit: Additionally, I have just tried the patch above on an older MacBook with Intel Graphics (still running 10.6.1 but with Max 5.0.7) and I get exactly the same problem.

edit2: Just to show fsmenubar affects this, I've uploaded a newer version that now if you press 'm' (has to be when not in fullscreen) it toggles fsmenubar on and off. When fsmenubar enabled I get no stuttering with the slab enabled or disabled. With fsmenubar disabled and the slab enabled I do get stuttering until i tab a different window on top and then with the output in the background, all is smooth!

This seems very similar to the problems I have with full screen on a second monitor after installing snow leopard, every thing works fine as long there is no jit.slab objects in the patch, but as soon there is I get 0-2fps and max becomes really unresponsive.

I have even contacted support about it but still no solution.

Nvidia Geforce 9600M GT 512m Vram ( mainly used )

This seems very similar to the problems I have with full screen on a second monitor after installing snow leopard, every thing works fine as long there is no jit.slab objects in the patch, but as soon there is I get 0-2fps and max becomes really unresponsive.
I have even contacted support about it but still no solution.

Macbook pro unibody 2.53 ghz
4gb ram
Nvidia Geforce 9600M GT 512m Vram ( mainly used )
Nvidia Geforce 9400M    256m Vram

whew..glad i saw this post..i was planning on upgrading to snow leopard soon, but my entire video performance patch relies on like 25 different slabs..so i may be waiting for a little while

we are taking a look at this. stay tuned.

As a possible workaround that seems to be fine on my 10.6 machine, use jit.window @rect and @border 0 to simulate fullscreen windowing.

i'got the same problem with a new mbp13'.

i'got the same problem with a new mbp13'.
what can i do please ?


wes : using your method works. but if you set rect exactly at the size of the main screen the fps fall down.

i mean, the mbd's screen is 1280. if i set "rect 1280 0 3204 768", it doesn't work ; but if i set "rect 1279 0 3203 768", it works.

rect does it better but only if i shift it one pixel

yeah got same problem here
mbp with th2g
 fullscreen gives bad fps
rect does it better but only if i shift it one pixel


robtherich wrote on Fri, 02 October 2009 20:59

robtherich wrote on Fri, 02 October 2009 20:59we are taking a look at this. stay tuned.

Can't believe I didn't think of this before, but if you set glreadback to "fbo", things will work smoothly. Seems to be a difference in pixelformat from the main context to the pbuffer in rtt mode. Try this in your patch to get normal speeds:

Can't believe I didn't think of this before, but if you set glreadback to "fbo", things will work smoothly.  Seems to be a difference in pixelformat from the main context to the pbuffer in rtt mode.  Try this in your patch to get normal speeds:

Your solution gives me amazing fps, but the resolution of my videos are extremely low.

It´s seems to be fine with jit.gl.videoplane but in my main video patch I m using jit.gl.mesh objects ( for corner pin correction).

I have attached a (somewhat) cleaned up version of my patch.

Your solution gives me amazing fps, but the resolution of my videos are extremely low.
It´s seems to be fine with jit.gl.videoplane but in my main video patch I m using jit.gl.mesh objects ( for corner pin correction).

wesley.hoke@gmail.com wrote on Tue, 13 October 2009 07:13

You sir, are a genius! Seems like the best temporary fix for the time being. I don't suppose you could explain (or point me to where I could find out) what glreadback is and the difference between fbo and rtt (and anything else). Googling it only seems to return threads that say use one or the other but no actual explanation.

wesley.hoke@gmail.com wrote on Tue, 13 October 2009 07:13Can't believe I didn't think of this before, but if you set glreadback to "fbo", things will work smoothly.  Seems to be a difference in pixelformat from the main context to the pbuffer in rtt mode.  Try this in your patch to get normal speeds:

It's a bit obfuscated based on the names rtt and fbo. Here are the details:

- rtt = use pbuffers for render to texture

- fbo = use frame buffer objects for render to texture

jit.gl.slab renders to texture internally in order to do its GPU pixel processing. When Jitter first added this capability, graphics card drivers were just on the verge of supporting fbos (pbuffers being the older technique and Jitter default). This was 5 or 6 years ago . Now, graphics cards all support fbos and for a number of technical reasons, this is the most efficient on newer GPUs.

Snow Leopard has a lot of under the hood changes, so I imagine something with pbuffers got whacked in the process since they're not the technique of choice these days.

It's a bit obfuscated based on the names rtt and fbo.  Here are the details:

- rtt = use pbuffers for render to texture
- fbo = use frame buffer objects for render to texture

jit.gl.slab renders to texture internally in order to do its GPU pixel processing.  When Jitter first added this capability, graphics card drivers were just on the verge of supporting fbos (pbuffers being the older technique and Jitter default).  This was 5 or 6 years ago  .  Now, graphics cards all support fbos and for a number of technical reasons, this is the most efficient on newer GPUs.

Snow Leopard has a lot of under the hood changes, so I imagine something with pbuffers got whacked in the process since they're not the technique of choice these days.


OK thanks that makes more sense now (although I will do a bit of googling around the subject too!). I guess the only Jitter related question I still have is that you seemed to give a pretty convincing argument to always set the glreadback to fbo. Would you agree or have I just read into it wrongly?

Fullscreen Slab Stuttering