Fast GL Preview Screens in Max 6

    Mar 25 2013 | 10:08 pm
    Hi there,
    I've been trying to get Preview screens set up through GL and included in this post is what I have so far.
    It seems that when you turn off the qmetros at the bottom of the patch, the framerate increases, Is this a sign that there is texture readback happening? I would like to keep everything smooth and as possible and over on the GPU.
    Any pointers would be great, thanks!!

    • Mar 25 2013 | 10:55 pm
      jit.pwindow always causes readback. Use jit.window instead.
      Also, you might wanna put qmetro at something larger than 5. That's 200fps. Or was that just for testing?
    • Mar 26 2013 | 9:26 am
      Yes, for testing.
      That's a shame about jit.pwindow, I guess some clever placement of jit.window should solve the problem.
      Thanks for your input!
    • Mar 26 2013 | 11:04 am
      It's 1 of the major GL performance traps. When people complain about low fps they often have their patch full of jit.pwindow's...
    • Mar 26 2013 | 11:06 am
      Now that I think of it, I'm not absolutely sure this is also the case when a pwindow is set as render destination of your context. It is for sure when routing for example a texture into a pwindow for monitoring. Your test patch seems to confirm it though.
    • Mar 26 2013 | 10:08 pm
      I've had another play with the patch, replacing the jit.pwindow with jit.window but that doesn't seem to affect things, it seems more to do with having the multiple render contexts...
      ironically, things seem to go back up to speed when the are connected to the jit.pwindows, but I believe that is doing unnecessary texture readbacks...
    • Mar 26 2013 | 10:17 pm
      Another thing to avoid is all those qmetro's. It's better to have 1 master clock / qmetro and distribute bangs with trigger objects.
    • Mar 26 2013 | 10:25 pm
      Ah, that was also for testing. ;-)
    • Mar 28 2013 | 1:30 am
      when jit.pwindow is used as a named rendering destination, as it is in this patch, there is no CPU readback. however if you send the output of a directly to a jit.pwindow, then there is a CPU readback.
      i should note, with max 6, you should avoid using the deprecated @shared_context attribute of, and instead use the @shared 1 flag or jit.window and jit.pwindow.
      i'm not sure if this will have much affect on performance of your patch, but it is the recommended way of sharing contexts.