Fullscreen Slab Stuttering

Oct 1, 2009 at 4:10pm

Fullscreen Slab Stuttering

Hello!

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.

Many thanks

DiGiTaLFX

edit: corrected graphics chipset

#45685
Oct 1, 2009 at 4:41pm

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?

thanks.

#164735
Oct 1, 2009 at 5:12pm

Hi I’m on OS X 10.6.1 using Max 5.0.8. The test videos I have been using are 640×360 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.

DiGiTaLFX

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!

#164736
Oct 1, 2009 at 7:29pm

Hello

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

Mac Os 10.6.1

Max 5.0.8

#164737
Oct 2, 2009 at 12:30am

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

#164738
Oct 2, 2009 at 7:59pm

we are taking a look at this. stay tuned.

#164739
Oct 3, 2009 at 11:26am

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.

wes

#164740
Oct 3, 2009 at 1:58pm

no news for this ?

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

#164741
Oct 3, 2009 at 6:32pm

hi,

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.

hope this help to resolve the problem.

#164742
Oct 3, 2009 at 8:52pm

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

#164743
Oct 4, 2009 at 12:34pm
robtherich wrote on Fri, 02 October 2009 20:59
we are taking a look at this. stay tuned.

Fab Very Happy

#164744
Oct 13, 2009 at 6:13am

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:

– Pasted Max Patch, click to expand. –

wes

#164745
Oct 13, 2009 at 12:07pm

Hi Wes

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.

any idea what might be going on?

/mattias

#164746
Oct 13, 2009 at 3:30pm

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:

– Pasted Max Patch, click to expand. –

wes

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.

DiGiTaLFX

#164747
Oct 15, 2009 at 4:57am

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 Smile . 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.

#164748
Oct 16, 2009 at 12:25pm

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?

#164749

You must be logged in to reply to this topic.