Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

DRobinson

macrumors newbie
Original poster
May 5, 2012
2
0
I've recently ported an OpenGL music visualizer I built for Windows over to my Mac.

I know that might make people jump to just blaming it on porting, but hear me out - the code was all system independent, that's not the issue.

The project uses: OpenGL, Boost Libraries (multithreading, etc.) and FMOD. I got everything running, but I noticed it seems to flicker a lot on high-action/high-refresh moments.

Here's the weird part: if I put the mouse/cursor over the Mac's dock/toolbar, and OSX uses the magnify effect, all of a sudden the framerate on my program skyrockets, and flickering disappears entirely!

This leads me to believe that the OS isn't going into some sort of graphics-mode and the GPU ( and maybe the CPU, too) is probably not running properly with just the program. As soon as something else triggers it, the graphics look fine.

Does that make sense in any way? Has anybody experience that, or otherwise does anybody have any ideas about a solution (other than just telling people where to park their cursors while the program runs lol)?

Thanks,
- Dylan
 

Starfox

macrumors 6502
Apr 7, 2011
256
9
I think BeamSync is why you're seeing that behavior. Do you have VSync on?
 

DRobinson

macrumors newbie
Original poster
May 5, 2012
2
0
I think BeamSync is why you're seeing that behavior. Do you have VSync on?

I hadn't really implemented VSync yet, in the application. Well, I have, but I didn't use GLUT's built in VSync because there are, apparently, issues that make it not so great.

Though it looks like BeamSync runs outside of the applications (from what Google's telling me). I can't seem to find any graphics options/settings. The macbook has an Intel GMA 3000, if that makes a difference as far as changing Beam Sync state goes.

One thing I notice is that in the little debug mode I've built into the application, it renders how long each frame takes to render (split into the different threads). In general, the background processing thread takes ~1500-2500 microseconds per frame - save for the occasional jump when a mutex is locked; the system doesn't spin locks that frequently - but as soon as I park the mouse over the dock and the effect's enabled, those numbers start showing up as 400-600 (huge improvement).

Actually, the thread's execution speed seems to improve as long as any other window is focused above the graphical application, too.

Anyway, I'm starting to think playing around with the time-related functions (clock_t and GLUT_ELAPSED_TIME) might be a better idea because it seems that they're giving a deeper granularity on OSX than on Windows (micro-vs-milli-seconds) and I'm starting to think that it could be the cause of the issues. Maybe. It's not a huge deal, but these types of things always get me curious :)
 

ender land

macrumors 6502a
Oct 26, 2010
876
0
Does this happen if you effectively only have this app running?

Are you using a macbook pro with two graphics cards?
 

Starfox

macrumors 6502
Apr 7, 2011
256
9
There's no GLUT built-in VSync. VSync is controlled by the swap interval parameter of the CGL Context and that's handled by the driver. Set that to 1 and your problems should go away.

http://developer.apple.com/library/mac/#qa/qa1521/_index.html

----------

Also, since you're using GLUT on OS X you should be able to toggle VSync from the Preferences window and get immediate feedback. Try that.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.