David Beaudry

I'm curious if anyone knows the cause of this. I have a couple different flavors of mac book pros (10.6.7) and have seen this behavior on all of them...even the latest and greatest. If I connect a second monitor and move the jit.window to that screen, I'll see the fps fluctuate between 30 and 60fps. This is with no processing just a bang to the renderer but no other processing with the other gl objects). And the odder part is that it's cyclical: every 15 seconds (almost exactly!) it will go thru a complete cycle of 60fps for several seconds, quick drop to 30 fps where it stays for several seconds, then quickly back to 60 fps.

Has any one else seen this? Just wondering if it is something special in my code. Even with the simple patch below (just a gl.render and jit.window) I see a cycle between 45 and 60.

cyclical-frame-rates

I am having a similar issue, tweaking settings, and so on does not affect the performance frame rate, which on my laptop screen performes at 60 fps, and when I move the jit.window on the 2nd screen starts to cycle, if I then swithc to fullscreen view frame rate drops dramatically to 22!

I searhced on the list and read some posts, seems that the issue of 5.1.2 is back? but why?

https://cycling74.com/forums/strange-frame-rate-issue-on-multi-output-installation

this is an unsolved error for a long time.

- dont use the fullscreen message, use the rect message instead

- cut 1 pixel of the width on the right side of your output window

(you definitly need this if you have more than 1 gpu)

sometimes it helps sending a border 0, border 1 messages to the jit.window

workaround:
- dont use the fullscreen message, use the rect message instead
- cut 1 pixel of the width on the right side of your output window
(you definitly need this if you have more than 1 gpu)

sometimes it helps sending a  border 0, border 1 messages to the jit.window 

If you happen to bang jit.gl.render before moving the jit.window to a second screen on my computer model one needs to (for achieving similar fps):

Render to another context screen (could be also a matrix),

then and only then tell to jit.render (again via drawto) to draw again on your jit.window (which now sould lie on the second screen).

It is the only way I found (and read ages ago on the forum, cannot really remember where) to avoid fps droppings when moving the window to a second screen.

For the window fps dropping in case of fullscreen on second monitor, I can tell only that the mentioned workaround works.

My 2 cents and with my laptop!
If you happen to bang jit.gl.render  before moving the jit.window to a second screen on my computer model one needs to (for achieving similar fps):
Render to another context screen (could be also a matrix),
then  move your jit.window,
then and only then tell to jit.render (again via drawto) to draw again on your jit.window (which now sould lie on the second screen).
It is the only way I found (and read ages ago on the forum, cannot really remember where) to avoid fps droppings when moving the window to a second screen.
For the window fps dropping in case of fullscreen on second monitor, I can tell only that the mentioned workaround works.

Max 5
OSx 10.6.8
Mbp 2,2 Intel 2 duo
4 GB RAM


Hey, all- just discovered this problem and these solutions aren't working for me. Fluctuating at either 60-30 or 30-15. This is a deal-breaker for a show I'm working on. Any ideas?

i haven't looked at your patch but here's a couple of things that help me out: - position the window with @pos @size, not fullscreen

- window @floating 1 (makes sure nothing is overlapping it)

and as always: get rid of graphical interface elements in your patcher window

i haven't looked at your patch but here's a couple of things that help me out: - position the window with @pos @size, not fullscreen
- window @floating 1 (makes sure nothing is overlapping it)
- turn off OSX's window shadows with http://unsanity.com/haxies/shadowkiller

and as always: get rid of graphical interface elements in your patcher window


I tried all of this and nothing works. I took out OpenGL from the equation and it still doesn't help. As I said this is a real deal-breaker for this show, and I imagine my work with jitter in the future. Any assistance would be appreciated.

this crashes my max as soon as i paste it in (or new form clipboard)...

i had a look at the previous patch you posted. 2 things:

- i 've never seen negative screen coordinates, don't know if that 's supposed to work

- you have the qmetro set at 2msec, which means it tries to run at 500fps. that's never going to run at a stable framerate cause it will jump up and down trying to get as high as it can when it's got free CPU/GPU cycles.

- i 've never seen negative screen coordinates, don't know if that 's supposed to work
- you have the qmetro set at 2msec, which means it tries to run at 500fps. that's never going to run at a stable framerate cause it will jump up and down trying to get as high as it can when it's got free CPU/GPU cycles.

btw, in my experience setting sync 1 on jit.window and running qmetro at the screen refresh rate is most stable.

Still no good with qmetro at 60hz. does it have to do with jit.qt.grab? If it helps, I'm on 6.0.4 and Lion

- Negative coordinates work when your screen is positioned to the left of your primary screen.

I get "jit.gl.context: no device for new gl context!" with your patch. Never seen this error before.

It'd be great to have someone from c74 weigh in on this- this seems like a pretty fundamental flaw.

took out c74 stuff, might work better for you:

Still no good with qmetro at 60hz. does it have to do with jit.qt.grab?  If it helps, I'm on 6.0.4 and Lion

- Yeah, qmetro 2 was a shot in the dark.
- Negative coordinates work when your screen is positioned to the left of your primary screen.

> I get "jit.gl.context: no device for new gl context!" with your patch. Never seen this error before.

that's because my 2nd screen is to the right, at x 1920. on your system jitter can't find a screen there, hence the error.

doesn't my adapted patch work for you when changing @pos x y to your setup?

that's because my 2nd screen is to the right, at x 1920. on your system jitter can't find a screen there, hence the error. 

doesn't my adapted patch work for you when changing @pos x y to your setup? 

Still no good. gl.render cycles between 59/60 and 39/41.

I'm running a new MBP 17". 8GB RAM, connecting to external monitor via Thunderbolt / HDMI.

I was going insane with this same issue and I figured it out. I'm now getting 60fps on three 1360x768 monitors using 1280 x 720 ProRes422(LT) with three separate nvidia cards.

Main thing I found is that dtr is right: you cannot have negative screen coordinates. You must rearrange your virtual monitor setup so that the externals are on the right and thus positive.

Special thanks to Vade, Andrew Benson and Scott Fitzgerald. Patch below.

I've been running into this issue again and spent a good while testing. This time I wanted to expand my setup with a 4th projector.

- working display on HDMI: 1920x1080 @ 60Hz

- 3 projectors connected to a triplehead2go on DVI: 2400x600 @ 85Hz

One OpenGL rendering context & window covers the triplehead output. Qmetro set at 85Hz, sync 0. This runs fine at 80+ fps.

Now when I connect the 4th projector to a mini-DP port (with a VGA dongle) and stretch the render window across it so it becomes 3200x600 the fps starts cycling between 80+ and 50-something fps.

If I leave the original 2400x600 window as is and add a second render context and window for the 4th projector instead: same thing, fps cycling.

But if I put that same second window on the HDMI display instead of the projector there's no cycling. I have a feeling that has to do with this display running at 60Hz instead of 85 like the projector. If I put the qmetro at 60Hz there's no cycling. But that's reducing potential performance by 25% to fix the issue and I would like to get the extra fps in my project...

Next thing I tried is taking out the HDMI display @ 60Hz out of the loop. Then there's only 2 displays both with a refresh rate of 85Hz. Cycling is much more moderate now between 80+ and 70 fps. Setting qmetro to 70 Hz shows no cycling. That's not ideal though acceptable but now I don't have a working/patching display... Possibly getting a display that works at 85Hz as well can resolve that.

So after testing all this an typing it here I tried something that 's a total long shot: change the main display to another than the HDMI screen. So I put OSX's menu bar (in display preferences) to the projector on the mini-DP port. Well what do you know: 80+fps steady! If I make the triplehead output the main display it doesn't work and I get fps cycling...

Attached is a screenshot of the working display arrangement. Left is the triplehead display on DVI, middle the 800x600 projector on mini-DP and right the 1920x1080 display on HDMI.

So my main conclusion is that there's a lot of voodoo going on behind the scenes at OS or hardware level and that we have little control over these things. There seems to be a big factor of luck involved in whether our particular setups are going to work optimally.

Any thoughts or experiences to share on the subject?

System: OSX 10.7.4 (hackintosh), Max 6.0.5, AMD Radeon HD6870 graphics card, i7 2600k cpu, 8GB 1600MHz ram

NB: I'm taking care of reinitializing the render contexts by toggling window floating after positioning etc. Putting the displays to the right or let of the desktop (positive or negative window coordinates) has no effect.

I've been running into this issue again and spent a good while testing. This time I wanted to expand my setup with a 4th projector. 

Original setup:
- working display on HDMI: 1920x1080 @ 60Hz
- 3 projectors connected to a triplehead2go on DVI: 2400x600 @ 85Hz

Now when I connect the 4th projector to a mini-DP port (with a VGA dongle) and stretch the render window across it so it becomes 3200x600 the fps starts cycling between 80+ and 50-something fps. 

But if I put that same second window on the HDMI display instead of the projector there's no cycling. I have a feeling that has to do with this display running at 60Hz instead of 85 like the projector. If I put the qmetro at 60Hz there's no cycling. But that's reducing potential performance by 25% to fix the issue and I would like to get the extra fps in my project... 

Next thing I tried is taking out the HDMI display @ 60Hz out of the loop. Then there's only 2 displays both with a refresh rate of 85Hz. Cycling is much more moderate now between 80+ and 70 fps. Setting qmetro to 70 Hz shows no cycling. That's not ideal though acceptable but now I don't have a working/patching display... Possibly getting a display that works at 85Hz as well can resolve that. 

So after testing all this an typing it here I tried something that 's a total long shot: change the main display to another than the HDMI screen. So I put OSX's menu bar (in display preferences) to the projector on the mini-DP port. Well what do you know: 80+fps steady! If I make the triplehead output the main display it doesn't work and I get fps cycling... 

Attached is a screenshot of the working display arrangement. Left is the triplehead display on DVI, middle the 800x600 projector on mini-DP and right the 1920x1080 display on HDMI.   

So my main conclusion is that there's a lot of voodoo going on behind the scenes at OS or hardware level and that we have little control over these things. There seems to be a big factor of luck involved in whether our particular setups are going to work optimally. 

Any thoughts or experiences to share on the subject? 

Oh and one render window stretching across triplehead + projector 4 results in cycling down to 70fps, regardless of which display is main.

And here's my previous run in with the issue, with a bit of clarification by wes smith: 

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

(in the current case I have sync=0 everywhere)

And here's my previous run in with the issue, with a bit of clarification by wes smith: https://cycling74.com/forums/gl-render-weirdness-fluctuating-fps-with-2-contexts-2-screens

(in the current case I have sync=0 everywhere)


Little update: I've upgraded my hackintosh with OSX 10.8.2 and an Nvidia GTX 660ti gfx card (from 10.7.4 and AMD HD6870). First tests show cyclical framerates aren't appearing anymore.

Tested with an empty render context spanning 2 triplehead2go outputs at 3x800x600 for a total of 4800x600 (1 window). Runs steady at around 220fps.

Tested with an empty render context spanning 2 triplehead2go outputs at 3x800x600 for a total of 4800x600 (1 window). Runs steady at around  220fps.


cyclical frame rates