|May 5, 2012, 02:22 PM||#1|
OpenGL Flickering issue (programming)
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)?
|May 6, 2012, 01:04 PM||#3|
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
|May 6, 2012, 07:48 PM||#5|
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.
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.
|Thread Tools||Search this Thread|
All times are GMT -5. The time now is 12:13 AM.