Forums > Jitter

Fast GL Preview Screens in Max 6

March 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!!


— Pasted Max Patch, click to expand. —

March 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?

March 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!


March 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…

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

March 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…

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

March 26, 2013 | 10:25 pm

Ah, that was also for testing. ;-)

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

Viewing 9 posts - 1 through 9 (of 9 total)

Forums > Jitter