|
|
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
|
|
|
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.
|
|
|
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!
|
|
|
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
|
|
|
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
|
|
|
Oct 2, 2009 at 7:59pm
we are taking a look at this. stay tuned.
|
|
|
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
|
|
|
Oct 3, 2009 at 1:58pm
no news for this ?
i’got the same problem with a new mbp13′.
what can i do please ?
|
|
|
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.
|
|
|
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
|
|
|
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 
|
|
|
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:
Copy all of the following text.Then, in Max, select New From Clipboard.
----------begin_max5_patcher----------
202.3ocSOFraCCBCF9L7Tf74toRi5zz1o9bzVUQHNYzQfJvQJsU8cuABYqW.
4u+Orw24Ln1OhQP7kXufwtyYrLJAXkZFzqF0VULqA8XLp5PX0bFgiTl+8gvY
CQXPzYCnpoVo+UzV6WDsFGp8Ctr8lBzMzabVjhuBa8NJZtgIlby6q+20OPKx
xBcFQWufyKA.hiknKJR+iw0cJfZZNsRtcpehpO+HcIKUSy3uGYZxaiu97aUR
3kejS0mGArKXTVHE7fySGhi7G7m.ZR8SyB
-----------end_max5_patcher-----------
wes
|
|
|
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
|
|
|
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:
Copy all of the following text.Then, in Max, select New From Clipboard.
----------begin_max5_patcher----------
202.3ocSOFraCCBCF9L7Tf74toRi5zz1o9bzVUQHNYzQfJvQJsU8cuABYqW.
4u+Orw24Ln1OhQP7kXufwtyYrLJAXkZFzqF0VULqA8XLp5PX0bFgiTl+8gvY
CQXPzYCnpoVo+UzV6WDsFGp8Ctr8lBzMzabVjhuBa8NJZtgIlby6q+20OPKx
xBcFQWufyKA.hiknKJR+iw0cJfZZNsRtcpehpO+HcIKUSy3uGYZxaiu97aUR
3kejS0mGArKXTVHE7fySGhi7G7m.ZR8SyB
-----------end_max5_patcher-----------
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
|
|
|
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  . 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.
|
|
|
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?
|
