Responsiveness problems in Yosemite: Menu-delay bug caused by ‘Reduce transparency’ option?

Posted by Pierre Igot in: Macintosh
December 19th, 2014 • 7:09 pm

When I was young and careless, I used to love being an early adopter of new technology, including computer technology. This meant that I often installed new system releases as soon as they became available, come what may. I was even quite excited when I was invited to join the AppleSeed program back in the early 2000s, because it meant that I would be able to use new versions of the system even before their official release.

Well, I am now older and wiser, and, more important, I have a lot of work that I need to do with my computer, which means that I cannot really afford to be so careless anymore. These days, I am increasingly cautious when it comes to experimenting with new builds of upcoming system releases, especially major system upgrades.

So when OS X 10.10 (Yosemite) came out, I didn’t install it right away. I read about it online, which is how I discovered, for instance, that there was an option to turn off the additional transparency “features” added by Apple to OS X in this new version. I saw absolutely no benefit to this additional transparency, and to me it was just the latest incarnation of Apple’s never-ending fascination with resource-wasting eye candy, which came to the fore (in a rather painful way) in the early days of OS X and has been plaguing every version of the system ever since. So I was relieved to see that at least Apple offered an option to reduce the transparency.

When the first incremental update of Yosemite (OS X 10.10.1) came out, I decided to finally take the plunge and upgrade my system. I figured that surely the worst bugs had been eliminated by then, and that the risk was fairly minimal.

As soon as I installed Yosemite, one of the first things I did was of course to activate the “Reduce transparency” option in the “Accessibility” preference pane. After all, if the option is there, it is meant to be used, and fully supported by Apple, right?


When it comes to Apple, it seems that things are never that simple. There has undeniably been a trend, in recent years, of letting quality standards slip and shipping stuff before it is actually ready for prime time. I am afraid that Yosemite has turned out to be a prime example of this.

As I have already explained in a couple of blog posts, in my experience, on a 2014 Mac Pro with 32 GB of RAM and a 1 TB SSD drive, driving two monitors via DisplayPort (an older 30″ Apple Cinema Display with a DisplayPort adapter, and a brand new 31.5″ Sharp PN-K321 display with a native DisplayPort connection), Yosemite feels distinctly sluggish.

I find this very disappointing. I specifically bought my rather expensive computer setup (in addition to the Mac Pro and the display, I also had to buy external Thunderbolt storage, of course) in anticipation of Yosemite, with what I thought was a guarantee that I would have, for years to come, a very fast machine that would be more than capable of handling my software requirements. (I don’t really do any hard-core audio or video editing, and so in some ways the Mac Pro is overkill, but I also want a very quiet machine and I don’t think that there’s anything else on the market that beats the new Mac Pro in that respect. Right now, all I can hear is my external Thunderbolt storage — and it is moving to another room in the basement very soon.)

Whereas things were quite zippy with Mavericks on the Mac Pro (with a few exceptions), as soon as I upgraded to Yosemite, I realized that this was not an OS optimized for speed and responsiveness. Even with the 10.10.1 update, basic interactions that involve the graphical user interface (GUI), such as switching apps, pulling down menus, resizing windows, etc., are sometimes unexpectedly and unexplainably sluggish.

I don’t know for sure if this is because Apple is so focused on battery-saving behaviours these days and feels that the majority of its users are willing to sacrifice a certain level of responsiveness in exchange for extended battery life on their laptops, but right now, my 2014 Mac Pro is only my “fastest Mac ever” on paper. In practice, I really feel, at times, as if we were back to the early days of OS X, when the hardware was desperately playing catch up with the software, especially because precious CPU cycles were wasted on “trendy junk”, a.k.a. “eye candy”. (I certainly remember how the pulsating Aqua buttons and animated progress bars felt on my Mac at the time…)

If that is the reality on my Mac Pro, I simply cannot imagine what it must be on other Mac computers, which are inevitably slower than the Mac Pro at a number of things.

A lot of my computing activities involve typing text and, overall, things aren’t too bad in Yosemite in that department. But I also rely heavily on keyboard-driven OS X automation tools such as Keyboard Maestro, LaunchBar and Typinator, and since the actions that are automated by these tools involve things that are normally done visually through the GUI, unfortunately, they are affected by responsiveness issues as well.

In addition, one particular area where Apple’s engineers appear to have really messed things up in Yosemite is accessibility, a feature on which these tools rely for executing their automatic processes. Because of this, I have had to rewrite or revise several of my Keyboard Maestro macros, and I have had to try and fine-tune LaunchBar’s settings, with mixed results so far. There are still things that do not work properly at all (using automated Tab keystrokes inside Open/Save dialog boxes in Keyboard Maestro macros, resizing windows in Preview with Keyboard Maestro macros, getting LaunchBar to hide its bar once the shortcut has been triggered, etc.). This means that, overall, my work environment has lost a significant amount of polish, smoothness and efficiency, and I am forced to do more things “manually” because Yosemite does not seem to be able to keep up with these automation tools. Yes, this, even on a 2014 Mac Pro with tons of RAM and a large SSD drive, which was working fine under Mavericks.

As regular readers of this blog and my Twitter feed know, one particular issue in Yosemite has been driving me up the wall in the past few weeks. It’s an issue that specifically involves the display of menus in the operating system: displaying menus under the menu headings in the menu bar, displaying menus under menu buttons or in front of pop-up controls in windows, etc.

Probably because of all the changes that Apple has made in Yosemite, with the switch to Helvetica Neue as the system font and new transparency “features”, there are now very visible and noticeable problems with displaying menus in OS X, at least on my machine (and on the machines of several people who have responded by email to my previous blog posts to confirm that they are experiencing similar issues).

When I click on a menu heading in the menu bar, instead of drawing both the blue highlighting behind the menu heading and the menu itself instantaneously, as it used to do, OS X seems to always need a fraction of a second to do so. It’s a tiny fraction, but it’s big enough to be noticeable, and to add to the feeling that the system is sluggish and unresponsive.

(I also highlighted, in a previous blog post, the specific behaviour of the “Help” menu, where the drawing of the blue highlighting is now so visibly slow that you can actually record the “filling down” of the rectangle with blue colour in real time with QuickTime Player.)

To be true, these problems do not seem to affect the usability of the menus themselves, and their impact is mostly of a subjective and “aesthetic” nature. Things just don’t feel right.

There is, however, one particular issue that is not just subjective and aesthetic in nature, and that is the one that I have been focusing on in the past couple of weeks, because it affects the usability of the system in a very real way. It took me a while to figure out exactly what was going on, but I eventually determined the following.

From time to time, when I click on a menu heading in the menu bar (in any application) or on a pop-up menu control in a window in Yosemite, instead of OS X showing the menu right away (even with the tiny delay mentioned above), nothing happens for several seconds. There is no change to the visual aspect of the control, and there is no Spinning Beach Ball of Death either. Then, after several seconds, all of a sudden the menu appears, but it just flashes for a fraction of a second and then immediately disappears again, without letting me select a menu item in it!

I then have to click on the same menu heading or control again, and this second time things work as expected.

There is absolutely no way to predict when this will happen. Sometimes, there is also an additional (and very noticeable) delay between the time the menu is displayed under the menu heading and the time the blue highlighting behind the menu heading itself is drawn.

It also does not matter whether I just execute a simple click action (i.e. a “click-and-release”) with the mouse button or a click-and-hold action (i.e. a click without releasing the mouse button). The latter, of course, used to be the only way to pull down menus a long time ago in Mac OS. But in both cases, the problem is the same. The menu-delay/flashing problem occurs with both types of clicking as far as I can tell.

As you can imagine, this problem, when it occurs on a regular basis, is downright infuriating, especially for someone who is used to working fast, like I am. My mouse-handling skills are of course not perfect (I’m only human), but they are pretty accurate, and, while I sometimes miss my target with the mouse, it’s relatively rare, and has nothing to do with this. (Indeed, the fact that the menu does eventually pull down or pop up, even if only fleetingly, proves that I did click on the target properly.)

It also does not matter whether I use the wireless Magic Mouse or the regular (wired) Apple Mouse. They are both affected.

Since I felt that this problem was clearly unacceptable on any machine, let alone on a fast machine like the 2014 Mac Pro, I decided to do something about it, even though I knew that it would be a time-consuming process, because the bug was intermittent, difficult to describe, and hard to reproduce reliably. But, assuming the eventual success of the process, I felt that the time spent on addressing the problem was worth it, simply because there was too much at stake. (I make my living with this machine, for crying out loud. And I have to try and retain my sanity.)

As I have said in my previous blog posts and on Twitter, as an experienced troubleshooter myself, I tried all kinds of things, to no avail. I won’t go into all the details here (this post is already long enough), but when I tell you that I even went as far as to do a so-called “clean install” of Yosemite after erasing the entire contents of my startup volume, if you’ve ever done this yourself, you’ll know that I really did try everything I could think of and could be reasonably expected of me as a Mac user.

I also spent quite a bit of time on the phone with Apple Care. I ended up talking to a couple of regular tech support people, and to two different senior advisors. They were mostly kind and understanding, and got me to do things that I couldn’t have done on my own (such as letting them remote-watch my system over the Internet using Apple Support’s proprietary tools, and also running data capture tools resulting in large log files destined to be uploaded to Apple’s servers).

But ultimately the whole process was very disappointing. The key thing was to try and get the senior advisors to talk to Apple’s engineers about this, and I did achieve this, but the initial response from the engineers was more than pathetic. Believe it or not, the first thing that they mentioned about the data captured on my system was that my system was being “spammed” (their word, not mine) with error messages such as these:

Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: MySpotlightImporter:persistentStoreCoordinator unable to add persistent store coordinator - Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f81226240b0 {NSSQLiteErrorDomain=14, NSUnderlyingException=I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'}
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: MySpotlightImporter:importFileAtPath:attributes:type: to find object id from path /Users/original/Library/Caches/Metadata/CoreData/DVDpedia/CCCF1415-9FB0-4846-B06E-9F265CFFD005/DVD/_records/6/1/0/p1634.pedia_md_d
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: CoreData: error: (14) I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'
Dec 11 15:27:03 Mac-Pro-2014.local mdworker[22216]: CoreData: error: -addPersistentStoreWithType:SQLite configuration:(null) URL:file:///Users/original/Library/Application%20Support/DVDpedia/Database.dvdpd options:{
	    NSReadOnlyPersistentStoreOption = 1;
	} ... returned error Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8122624210 {NSSQLiteErrorDomain=14, NSUnderlyingException=I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file'} with userInfo dictionary {
	    NSSQLiteErrorDomain = 14;
	    NSUnderlyingException = "I/O error for database at /Users/original/Library/Application Support/DVDpedia/Database.dvdpd.  SQLite error code:14, 'unable to open database file’";

To them, it was somehow an indication that there might be something uniquely wrong with my system, and that it had to do with something called “DVDpedia”, which apparently they had never heard of.

DVDpedia is part of a family of applications made by a developer named Bruji, which are an excellent alternative to the increasingly bloated and underwhelming Delicious Library (a tool that I gave up on after the last major upgrade).

DVDpedia is even sold through the Mac App Store!

It boggled my mind that Apple’s engineers apparently could not be bothered to look it up and figure out what DVDpedia was themselves. And it boggles my mind that they would even think that this was the cause of my problem.

DVDpedia is a stand-alone application that manages a database containing records of one’s collection of DVD and Blu-Ray disks (using data pulled from Amazon and other sources). In my mind, there was just no way that this app could cause the responsiveness problem with menus that I was experiencing. As I told the senior advisor, I was even able to reproduce the problem on my clean install of Yosemite before I reinstalled DVDpedia (which I don’t need for my work and is only for my personal use).

In addition, while I am not a developer, I see clearly from the log quoted above that the problem involves not the DVDpedia application itself, but the mdworker process, which is an OS X process used for Spotlight indexing. How could DVDpedia even be blamed for this?

Still, to be thorough, I did contact Bruji via Twitter and their prompt answer was unequivocal:

A warning from a bug in the Apple Spotlight framework, harmless. You can delete Caches/Metadata/CoreData/DVDpedia to fix.

So there you go. Instead of taking my complaints seriously, Apple’s engineers clearly did their utmost to try and find a third-party tool that might be responsible for my problems, even after all the troubleshooting work that I had done.

Now, of course, I couldn’t rule out the involvement of third-party software in this bug entirely, especially because the bug was hard to reproduce on a clean system before reinstalling all kinds of ordinary apps (iWork, Microsoft Office, Adobe Creative Suite, etc.). But, having eliminated any software that involved kernel extensions and the like, I was finding it difficult, if not impossible, to imagine that a regular, stand-alone application with no nasty behind-the-scenes process running in the background could explain, all by itself, a system-wide bug such as the one that I was experiencing.

I don’t know if the initial response from the engineers was due to communication issues with the senior advisor or simply to a lack of goodwill on their part (I suspect the latter), but I still find it shocking that they couldn’t even look into the DVDpedia thing themselves before getting back to me with that as a response.

Nonetheless, I did turn the Spotlight indexing of DVDpedia stuff off by following instructions provided by Bruji, and produced a new set of data for the engineers to examine, presumably without the “spamming” identified above. (I don’t know where they got these logged error messages from. I couldn’t find them myself via the Console.)

But that’s all I’ve heard from engineers so far, except for a separate response from the bug report that I submitted independently, via Bug Reporter a while ago, which eventually elicited a generic “Bug report is a duplicatemessage. This might be viewed as encouraging, except that, in reality, it only confirms that I am not the only one suffering from the problem. It gives no indication of whether the engineers are able to reproduce the problem themselves or working on a fix.

Meanwhile, the beauty of the Internet is, of course, that, by talking about this on my blog and on Twitter, I managed to elicit various responses from readers. Some shared Yosemite problems that had nothing to do with mine. But other shared that they too were suffering from the exact same menu-delay/flashing problem as the one I was experiencing.

Eventually, one of those readers suggested that I try turning on the “Increase contrast” option in the “Accessibility” preference pane in System Preferences, under Vision › Display. Apparently, this was helping him alleviate the problem somewhat.

Even though the increased contrast results in a fairly ugly visual interface, I was able to confirm that, on my machine at least, it did seem to not just alleviate the problem, but actually eliminate the menu-delay/flashing problem altogether!

Since the “Increase contrast” feature actually (and logically) automatically disables the “Reduce transparency” feature at the same time, I figured that the next step would be to try and reproduce the menu-delay/flashing problem without the “Increase contrast” setting turned on, but also without the “Reduce transparency” setting turned on.

(As mentioned above, turning on the “Reduce transparency” setting was one of the first things that I did after installing Yosemite.)

That was a couple of days ago, so maybe it’s still too early to tell. But so far, with both “Reduce transparency” and “Increase contrast” off — i.e. with the default values for these settings in Yosemite, I haven’t been able to reproduce the menu-delay/flashing problem.

Then this morning I turned the “Reduce transparency” setting back on, just to see. And within an hour, I was able to reproduce the menu-delay/flashing problem once. Needless to say, I have turned it back off.

The most reasonable conclusion for me at this point is that there is something wrong with Yosemite, and that the “Reduce transparency” feature actually makes it worse, much worse. It triggers a serious responsiveness issue that has a major impact on usability, whereas with the feature off, the responsiveness issue appears to remain dormant or at least be limited to “only” a general feeling of sluggishness.

Still, I am sure that there are tons of other users who are also using this “Reduce transparency” feature, which is well documented. (I am far from being alone in finding this extra transparency totally useless and distracting, to say the least.) So, if the menu-delay/flashing problem is indeed caused by this feature, how come there aren’t more people complaining about it and bringing it to Apple’s attention?

My theory at this point, based on the multiple troubleshooting steps that I have taken, is that the severity of the menu-delay/flashing problem itself is not identical for everyone, and depends on a variety of factors, including the size and number of displays used. I have two large screens and I have noticed that the problem is less prevalent if I only use the big Sharp screen, and even less prevalent if I only use the (smaller) Cinema Display. (But it’s still there, even with only one smaller display. It’s just far more intermittent, and the delays don’t seem to be as long.) It is also possible that this problem only affects certain Mac models, including the 2013/2014 Mac Pro and also (at the very least) some MacBook Pros, possibly because they use a certain kind of video card.

I wouldn’t be surprised, at this stage, if the severity of the bug was actually proportional to the number of pixels that the video cards in those machines have to handle, and also if it was affected by some other general factors, such as the amount of RAM currently in use (because the problem is definitely more noticeable when there are more apps running, even if they are not doing anything or using any CPU power).

This whole mess also highlights a couple of significant ironies:

  • This menu-delay/flashing problem when “Reduce transparency” is on effectively means that, far from improving system responsiveness by eliminating the waste of resources for useless eye candy, this accessibility feature actually make Yosemite less responsive. (This is also why I never thought that this feature was a possible suspect in all this, and I am eternally grateful to the Betalogue reader who brought it to my attention. I don’t know where he got the idea from.)
  • It is possible that this menu-delay/flashing problem only affects a specific category of machines, which happens to be a range of pro-level machines that people buy precisely because they seek power and high performance levels. So they, like me, pay a premium for quality hardware, and now they end up being somehow punished for it!
  • Spending hours on the problem with Apple Care yielded nothing, but sharing my problems with others online enabled me to find an apparent solution by myself.

I honestly find the response I have received from Apple Care (and from Apple engineers via Apple Care) so far severely insufficient. The very fact that, aside from this particular bug, Yosemite feels sluggish, even on a fast machine, is to me an indication that Apple’s priorities lie elsewhere and that they do not take performance issues seriously enough.

I realize that these issues are hard to describe, reproduce, and observe. But with the resources at its disposal, Apple has an obligation to engage in a serious effort of improving quality control and quality assurance processes. It is simply unacceptable that such a bug is allowed to slip through.

Allowing people to use beta software is all well and good, but it’s not an excuse for not doing your own testing in-house, recreating real-world configurations (with displays of various sizes and combinations, and third-party software from all kinds of sources and in all kinds of combinations).

Also, when I see how Apple tends to responds to the bug reports that I submit either via Bug Reporter or as part of my involvement with AppleSeed, I have serious reservations about the effectiveness of their communication system.

Right now, I am beta-testing the next build of OS X 10.10.2 on a separate partition. I am not allowed to talk about features or anything like that, but there is one serious new, 100% reproducible bug (on my machine at least) that causes a kernel panic every time I trigger it. I have sent a detailed bug report about it, but because it involves my specific system configuration and a couple of third-party hardware devices (external Thunderbolt storage, which I have no choice but to use with the storage-deprived Mac Pro!), I am not optimistic that the bug will be fixed by the time 10.10.2 comes out. Maybe it will. But I won’t be surprised if it isn’t. And if it isn’t, I’ll be deprived of any further improvements made to Yosemite until Apple fixes it, which could take months.

This whole experience has been quite traumatic for me as a Mac user. The menu-delay/flashing problem was driving me insane in my daily use of my Mac, and I sure hope that switching the transparency back on, regardless of how much I loathe it, keeps it at bay permanently.

But more generally, I still find the overall sluggishness of Yosemite unacceptable. I certainly expect better performance from a 2014 Mac Pro with tons of RAM and a fast SSD. I simply should not have to wait a couple of seconds when switching apps, for instance, especially when these apps are not doing anything significant at the time.

Is there anyone at Apple who cares about all this? Anyone who has the power to do anything about it? I do not know, but this general sloppiness and the lack of transparent (!) communication when real problems occur are highly problematic. I really feel that Apple has enough money in the bank to do a much better job of supporting its Mac users and providing them with a top-quality computing experience. I really feel that, as Mac users, we have yet to see the real benefits of the great financial boom that Apple has experienced in the past ten years or so.

2 Responses to “Responsiveness problems in Yosemite: Menu-delay bug caused by ‘Reduce transparency’ option?”

  1. Betalogue » OS X 10.10 (Yosemite): Preview fails to keep up with fast window resizing says:

    […] is the kind of thing that they are thinking about. It took me a while to narrow it down because of all the other responsiveness problems I had with Yosemite, but this, as far as I can tell, is an easily reproducible problem for anyone […]

  2. Betalogue » OS X 10.10.3: Fixes major responsiveness issues on 2014 Mac Pro says:

    […] has been a very traumatic few months for me as a Mac user. As indicated in several previous blog posts, I purchased a new Mac Pro along with a new 4K display back in July 2014. The machine shipped with […]