Strange frame rate issue on multi-output installation

    Oct 25 2011 | 10:56 pm
    Am running into a strange problem with an installation that uses multiple video outputs.
    Basically, frame rate drops to 11fps on the fullscreen output windows UNLESS the patch window slightly overlaps one of the outputs. When the edge of the patch window slightly overlaps, then framerate goes back up to 30fps.
    The system has three graphics cards installed, with a projector on each output. A control monitor is connected to the second output of one of the cards.
    What could be going on here? I am using OpenGL to create a separate render context for each video output, and I suspect the problem is connected to how these contexts are created, and fullscreen rendering invoked.
    To make it even more mysterious, this patch + hardware configuration worked perfectly for 11 months in another setting.

    • Oct 25 2011 | 11:28 pm
      This is a really weird, known but elusive issue. Very machine and OS specific. The workaround is to use @border0 and a window size with one pixel less than the screen size. As best as we can tell it is a bug in Apple's window compositing system.
    • Oct 26 2011 | 7:06 am
      the patcher window overlaps the output that is not on the same gpu ?
      you did separate gl contexts and separeate textures . (check)
      also first place the on the right gpu's and then bang the
      2 years ago i did a project with 7 outputs + control output
      on a macpro with 4 gpu's . 4 separate gl contexts and using shared context on each gpu .
      had a lot of gpu crashes ...
      but with the new 10.7 i have even more gpu - kernal panics .
      you are on 10.7 now ?
    • Oct 29 2011 | 11:10 am
      I have reliable results by using jit.window @size of the projectionscreen and @pos leftmost vertical/horizontal pixel.(avoiding the fullscreenmode of jit.window) It seams to anchor the image.
      Does this help?
    • Oct 31 2011 | 4:55 am
      Thanks for all the help!
      Reverting to an earlier version of the Max runtime seems to have solved the problem. Will gather some more info and post solution.
      What Helmuth describes seems like a good workaround, and is easy to implement in the patch.