Vincent Goudard

Running the exact same patch in Max6 and Max5 yields very different performance results.

If I use the jit.gl.render help patcher, set the metro to 15ms and go fullscreen, I get :

- in Max 6.0.8 : only 30fps when going fullscreen.

Is there any way to tweak some option to reach Max5 performance ?

This was tested on a macbook pro 2.8Ghz Intel Core 2 Duo with 4Go 1067MHz DD3 Ram, OSX 10.7.4

Running the exact same patch in Max6 and Max5 yields very different performance results.
If I use the jit.gl.render help patcher, set the metro to 15ms and go fullscreen, I get :
- in Max 5.1.9 : about 40 fps
- in Max 6.0.8 : only 30fps when going fullscreen.

That is quite a big performance loss...
Is there any way to tweak some option to reach Max5 performance ?
What is the reason for this loss ?

This was tested on a macbook pro 2.8Ghz Intel Core 2 Duo with 4Go 1067MHz DD3 Ram, OSX 10.7.4


low-opengl-performance-in-max6

The qmetro in the 5.1.9 help patch is set to '20', whereas in the Max 6 help patch, it is set to 33. When I either change the qmetro or use the old help patcher in Max 6, I see identical performance.

Let us know if you are still having performance issues.

The qmetro in the 5.1.9 help patch is set to '20', whereas in the Max 6 help patch, it is set to 33.  When I either change the qmetro or use the old help patcher in Max 6, I see identical performance.

Here's a patch with observed performance on Max5 and Max6, with a MacBookPro 2.8GHz Intel Core 2 Duo with 4Go 1067MHz DDR3 RAM, OSX 10.7.4. Full screen was tested on a 2nd screen (ACER V173) 1280x1024px, 75hz

... which makes Max6 approx. 8pts behing Max5 performance.

thanks for the reply.
Here's a patch with observed performance on Max5 and Max6, with a MacBookPro 2.8GHz Intel Core 2 Duo with 4Go 1067MHz DDR3 RAM, OSX 10.7.4. Full screen was tested on a 2nd screen (ACER V173) 1280x1024px, 75hz

on max5 :
reduced window (320x240) : 59
full screen : 36

max6:
reduced window (320x240) : 59
full screen : 29

... which makes Max6 approx. 8pts behing Max5 performance.
Do you get the same hit ?

Ah, the joys of GL optimization. I've been pulling out my hair over this sort of thing way too often... Especially with multi-screen setups unexplainable things happen that seem to be bound to specific hardware configurations.

That said, your patch is a bit flawed. It will never exceed 60 (or 75) Hz because you have @sync 1 set on your window. That locks rendering to the refresh rate of the display.

Also, it's rumored that fullscreen mode is less efficient than setting size and position explicitly. I haven't verified that but below 's a revised patch anyway. Window size set to my MBP's resolution, adapt to your needs. For second display, change the pos x y message so it starts at the first x coordinate of the 2nd display.

I'll do the fps test when I get to my machine that also has Max 5 on it. 

That said, your patch is a bit flawed. It will never exceed 60 (or 75) Hz because you have @sync 1 set on your window. That locks rendering to the refresh rate of the display. 

Also, it's rumored that fullscreen mode is less efficient than setting size and position explicitly. I haven't verified that but below 's a revised patch anyway. Window size set to my MBP's resolution, adapt to your needs. For second display, change the pos x y message so it starts at the first x coordinate of the 2nd display.  

I'll do the fps test when I get to my machine that also has Max 5 on it. 


I am aware of the sync attribute limiting fps to the screen refresh rate. However, I was still far from the 75Hz of my screen to consider this as an issue.

I confirm that setting window size and position explicitely enhance the performance. Namely I get 40fps instead of 30fps with the patch previously posted, when going fullscreen in Max6. (fwiw, I tested on Max6.0.8 and Max6.1.0 ). Thanks for the info !

jit.gl.node yields better results when running an equivalent setup, but I get bugs with textures which make it an unsatisfying solution at the moment (plus the fact that i have to adapt a complex patch using this system). I'll post the buggy behaviour from jit.gl.node in another thread.

thanks dtr for the reply.
I am aware of the sync attribute limiting fps to the screen refresh rate. However, I was still far from the 75Hz of my screen to consider this as an issue.

jit.gl.node yields better results when running an equivalent setup, but I get bugs with textures which make it an unsatisfying solution at the moment (plus the fact that i have to adapt a complex patch using this system). I'll post the buggy behaviour from jit.gl.node in another thread.


Here are some fun reads on the (broad) subject:

https://cycling74.com/forums/gl-render-weirdness-fluctuating-fps-with-2-contexts-2-screens

https://cycling74.com/forums/cyclical-frame-rates

Not sure how much of it applies to the current Max and OS versions.

Here are some fun reads on the (broad) subject:
https://cycling74.com/forums/gl-render-weirdness-fluctuating-fps-with-2-contexts-2-screens
https://cycling74.com/forums/cyclical-frame-rates

Not sure how much of it applies to the current Max and OS versions.


This may be relevant to this discussion. We have discovered a problem with retina screens where Max is redundantly calculating 4 times the number of pixels for the display. This only affects retina machines.

To work around this, 'Get Info' on the Max Application and then check the "Open in Low Resolution" check box.

We're looking at adding some kind of compatibility mode to this, but in the meantime, if you are experiencing problems with performance, running Max this way should help.

This may be relevant to this discussion.  We have discovered a problem with retina screens where Max is redundantly calculating 4 times the number of pixels for the display.  This only affects retina machines.

However, I am not concerned by retina display...

I am heading toward jit.gl.node based system, but still get a lot of trouble.

Here are the features I am trying to get :

- Render each GL object to 0 to N destination.

- being able to switch dynamically between what is rendered where

- being able to render a destination to itself to achieve nice feedback effects (that one can easily and powerfully modulate with camera setting)

- have the jit.gl.node, jit.gl.camera, jit.gl.whatever in distant patchers (no patchcord between them)

- being able to attach texture from a texture bank to whatever object in whatever rendering pass

It is possible to do such things with to_texture method (cf examples from Andrew Benson and Vade) but jit.gl.node seems more optimized (especially to set various rendering parameters, like camera and such for each rendering pass).

Is there a tutorial somewhere to go this way with jit.gl.node ?

thanks Ben for the hint.
However, I am not concerned by retina display...
I am heading toward jit.gl.node based system, but still get a lot of trouble.

Here are the features I am trying to get :
- Render each GL object to 0 to N destination.
- being able to switch dynamically between what is rendered where
- being able to render a destination to itself to achieve nice feedback effects (that one can easily and powerfully modulate with camera setting)
- have the jit.gl.node, jit.gl.camera, jit.gl.whatever in distant patchers (no patchcord between them)
- being able to attach texture from a texture bank to whatever object in whatever rendering pass

It is possible to do such things with to_texture method (cf examples from Andrew Benson and Vade) but jit.gl.node seems more optimized (especially to set various rendering parameters, like camera and such for each rendering pass). 

Is there a tutorial somewhere to go this way with jit.gl.node ?


If you are looking for some jit.gl.node feedback examples, check out some of the more recent Jitter Recipes:

https://cycling74.com/category/articles/jitter-recipes/

If you are looking for some jit.gl.node feedback examples, check out some of the more recent Jitter Recipes:
https://cycling74.com/category/articles/jitter-recipes/


low OpenGL performance in Max6 ?