Najib has found that when using a recent MWorks build under Snow Leopard and displaying stimuli on a secondary monitor, the secondary monitor flickers very obviously during stimulus updates. This doesn’t happen when running the same MWorks build under Leopard.
Curiously, this problem manifested only recently, even though Najib has been running MWorks under Snow Leopard for several months. This suggests that the problem may have been introduced by a recent Snow Leopard update (most likely 10.6.3, which included OpenGL-related changes).
I’ve reproduced the flickering problem on my own setup and verified that the issue stems from a post-10.6.0 update to Snow Leopard.
Specifically, I first upgraded a Tiger installation to 10.6.0 and ran Najib’s experiment, which produced no flickering on the secondary monitor. Then, I ran Software Update and updated the system to 10.6.3. After that, I re-ran Najib’s experiment and saw very obvious flickering on the secondary monitor.
Since the 10.6.2 update was released back in November 2009, and Najib was able to run his experiment without flickering a month or two ago (presumably with an up-to-date Snow Leopard install), I’m guessing that the flickering issue wasn’t present in 10.6.2. Hence, it must be related to OS changes introduced in 10.6.3.
We haven’t seen it yet it my lab, but we haven’t upgraded to 10.6.3 on production machines yet. Davide, however, just emailed me about a display issue with a new Mac Mini that he just purchased that came with 10.6.3 installed stock. We haven’t had a chance yet to sync up about this issue, but I’d be surprised if it was something different.
I also wouldn’t be surprised if this were related somehow to the NVIDIA 9400M display bug that appeared on late 10.5 updates, but disappeared with the arrival of 10.6.
My initial guesses at what could be happening:
-
Changes in the behavior of the FENCE OpenGl extension. This made more sense when the problem was related to the display updates going slow, but I haven’t seen the new bug yet, so perhaps this is something to explore. Simply turning off the fence should rule this out (e.g. take out the #define USE_GL_FENCE)
-
Changes in CoreGraphics API calls. 10.6.3 appears to have made significant changes in CoreGraphics, and MWorks currently makes some CG*** C-API calls to set up external monitor OpenGL contexts. This code is some of the very oldest in MWorks could really use a solid going-over anyways, but it has worked flawlessly for many years, so it hasn’t been a priority. Clearly now that priority is upgraded.
Questions I have for those that can produce the bug:
-
What kind of flicker do you see. Is it a classic frame tear (i.e. top half-ish of the image appears for a split second by itself before the rest of the image appears)? This would imply that the VBL sync property is not getting set correctly on the context.
-
What graphics hardware are you using. Previously we saw display problems only with one particular NVIDIA chipset and only when running on an external monitor config. Is this on a laptop chipset? NVIDIA? ATI? This might give us some kind of clue about what’s going on.
More signs of something unusual afoot in the OpenGL drivers under 10.6.3. Looks like OpenGL performance regressed, and there are some other weird signs (like higher resolution benchmarks posting higher frame rates than lower resolution ones):
Benchmarks:
http://discussions.apple.com/thread.jspa?threadID=2382458&tstart=0
Frame Tears in Maya:
Hey Dave,
- What kind of flicker do you see. Is it a classic frame tear (i.e. top half-ish of the image appears for a split second by itself before the rest of the image appears)? This would imply that the VBL sync property is not getting set correctly on the context.
It doesn’t look like frame tear to me. Rather, the whole screen flickers at once, almost as if there’s a full-screen frame of solid black that precedes/follows every frame drawn by MWorks.
- What graphics hardware are you using. Previously we saw display problems only with one particular NVIDIA chipset and only when running on an external monitor config. Is this on a laptop chipset? NVIDIA? ATI? This might give us some kind of clue about what’s going on.
Najib and I both saw the problem on Mac Pros. Mine has a NVIDIA GeForce 7300 GT, but I think Najib has an ATI card.
OK, so on my laptop, running 10.6.3, with the 9400M graphics enabled (9600M GT discrete graphics disabled), I’m not seeing any glitches like the ones you describe in stimulus presentation, across a range of different experiments.
I can also try with the discrete graphics enabled, but perhaps someone could create a minimal test case that produces the bug so that we can rule out that source of variation and run it across a variety of different configurations?
the quality of the glitch is completely different for and LCD display versus a CRT display.
you can miss if you don’t have multiple update in a row, i can definitely see it in the “woof.xml” example experiment.
for a CRT there is an obvious tear midway down a screen.
for an LCD there is a flicker, the entire screen turns black when it shouldn’t, you want see it if you are background color is black, you only see it if your background is gray.
as i mentioned in an earlier email, this happens with both an ATI Radeon X1900 XT, and a NIVIDIA GeForce 7300 GT card.
To clarify, the protocols that I don’t see a problem on include:
Woof.xml (in the /Document/MWorks path of my install)
ShowStimulus.xml
MultidimensionalStimulusTest.xml
… and some drifting grating tests that we have internally (with smooth 30Hz updates).
All of them (except the last one) have gray backgrounds, and I’m using an LCD monitor.
My “Woof.xml” does not include multiple updates in a row – it just repeatedly shows a picture of a golden retriever for a second or two, synced with a wolf howling noise. Is this the same one you have?
My install is live from a lightly-modified branch at the moment (though I’d be very surprised if anything I’ve done in this branch magically “fixed” your problem), and I haven’t reverted back to a “known” version yet, but I’d like to nail down the conditions to reproduce before I do.
I’ve found a fix that eliminates the problem.
This discussion quotes a fix for the problem with Maya:
What I found fixes them is if you boot Maya from the OpenGL profiler (Developers tool application) and click the “Use custom pixel format” checkbox. Click the “Edit” button next to it and in the new window that pops up, double click “kCGLPFABackingStore” and under the “Value” change it to a “1”. Now you can press the Launch button in the main OpenGL Profiler window and Maya should be working OK. It’ll behave the way it did before the update to 10.6.3.
Searching through the mw_core source, I found the following, commented-out line (Core/Stimuli/OpenGLContextManager.cpp:630):
// NSOpenGLPFABackingStore,(NSOpenGLPixelFormatAttribute) 1,
I uncommented that line, recompiled MWorksCore.framework, and dropped the new MWorksCore binary onto my Mac Pro. After that, I no longer see flickering when running Najib’s experiment.
I don’t know anything about that particular OpenGL setting (NSOpenGLPFABackingStore), so I don’t know if this change will have other ramifications. Dave, any thoughts?
Some potentially-relevant docs regarding NSOpenGLPFABackingStore:
Great catch.
I’m not sure I fully understand the circumstances under which that option should or shouldn’t be set (and my initial read of the documentation makes it even less clear to me). My initial experience with getting that code setup correctly in the first place was that it was a fiddly and fragile API (circa 10.2, at least), and I vaguely recall having to comment out that line to get the fullscreen context to work properly.
The example OpenGL fullscreen context code appears to be a continually moving target. Apropos to this, there is a new recipe (specific to 10.6) in the documentation you linked. Looks like they finally enabled the fullscreen support in pure Cocoa code (without resorting to any CoreGraphics calls). We probably will want to follow this new recipe, to avoid future hiccups.
i am quite surprised that are not seeing the flicker. are you using an external monitor?
it is hard to see with “woof.xml” because the updates are so infrequent.
in any case, i just chris just patched my mworks with his solution.
we tried it before the patch and the flicker was clear, with the patch the flicker was gone.
the main thing next is to insure that his patch didn’t break anything else.
Yes, I am using an external display. The updates for the drifting grating protocols are happening at 30Hz, so if there was a problem with updates per se, I’d see it.
I think it likely to be hardware dependent – different graphics cards can have very different buffer implementations, and the GPU in my laptop is several generations newer than your Mac Pro’s GPU. We’ve already seen at least one other problem that does not uniformly affect all GPUs.
I’ll try the patch on my system as well to see if anything breaks.
Hi guys,
we have recently experienced the same issue in my lab.
The first instance happened on a Mac Mini that was recently updated from 10.6.2 to 10.6.3. Then, we also verified that the same happens on a MacBook with 10.6.3 and an external monitor attached.
In both cases it seems that images loaded as png files display ok, but a mask plugin that we built in our lab using openGL shows the flickering: stim+mask appear very briefly for a fraction of a sec, then a blank screen appear for 1 sec or more, then again the stim+mask, etc. for 3 times usually.
About the fix that Chris found, what are your short and long-term plans Dave?
Are you planning on releasing a new build of MW that incorporates the fix? Or should we download the MW core, make the fix ourself, recompile, and build an install? I assume that, if we do this, it would be ok to install this fixed MW only on the Mac Mini running the server (and not on the iMac running the client and on all other Mac Minis that still run 10.6.2).
Davide,
Sounds like this is likely to be a related issue, though the timing sounds potentially different.
I’ll make a fresh build with the backing-store enabled that you can have to test.
– Dave
I’ve created a ticket for this issue in Lighthouse.
Dave, should I commit my patch, or is there more testing you’d like to do first?
Feel free to commit. We’re not seeing glitches over here, with or without the patch. Not sure what the difference is (presumably hardware), but not sure the answer matters all that much either. We should move to the new-style, all-Cocoa context creation code when we drop 10.5 support eventually.
– Dave
OK, I committed my fix and marked the issue resolved. I also created a new ticket for the switch to the new-style context creation code.
Dave,
can you make a build for me with this fix, so that I can test it on my
Mac Mini with OS 10.6.3 (sever side)?
davide
Hi Davide,
Are you still waiting for a build with the OpenGL fix? If so, you can try my nightly build. It doesn’t include any CoxLab plugins (which maybe you’re using), but you can at least use it to verify that my fix solves your problem, too.
For download and install instructions, see
https://mworks.tenderapp.com/faqs/installation/install-mworks
Chris