Video freezes on Mac Pro: It was software after all

Posted by Pierre Igot in: Macintosh
January 21st, 2017 • 6:35 pm

I have an update on the situation with my Mac Pro that I blogged about in December

Back then, I indicated that the unpredictable video freezes that I had been experiencing for a while appeared to be gone after I had had one of my video cards replaced by Apple under warranty.

If you follow me on Twitter, you know that this is not where the story ends.

In fact, after the video card swap on December 11, the Mac behaved properly for exactly two weeks and then… out of the blue, I started experiencing video freezes again, on December 25. (Yes, on Christmas day!) The symptoms were exactly the same again: normal behaviour for a long time, and then, all of a sudden, a cascade of temporary video freezes, accompanied by the display of this error message in the system log:

Mac-Pro kernel[0]: stalling for detach from AMDTahitiGraphicsAccelerator

The video freezes would last several minutes, and then things would go back to normal… until the next time, which could be 15 minutes later, 12 hours later, or 72 hours later. There was no way to predict it.

How was this possible? This clearly indicated that the problem was not fixed by the video card swap, and that the “purple tinge” that the Genius Bar staff member had noticed with my video card when using his advanced testing tools was unrelated to the actual problem. Swapping the video card might have fixed the “purple tinge” (which I never experienced myself under normal conditions), but it didn’t fix the video freezes.

Needless to say, since the video freezes started happening on Christmas Day, I didn’t do anything about them right away. Apple’s services were closed on December 25 and 26 anyway, and I figured that they would be swamped with calls on December 27 from people with trivial problems with their new Apple-made Christmas gifts. So I knew I had to wait a few days.

I also was on holiday and didn’t exactly relish the thought of spending several hours of that time off on the phone with various Apple representatives trying to convince them to do something about the problem.

So I just continued using my computer normally, trying to put up with the freezes and not let them drive me mad. Then, the next time they happened, I noticed something that I hadn’t noticed before. One of the ways that the problem first manifested itself was not necessarily with a complete video freeze of the entire interface (except the mouse pointer), but with a web page failing to load in Safari. A page that I had just visited a moment ago and wanted to go back to wouldn’t load. Instead, I would be faced with a blank window, with no explanation. My Internet connection was still working fine, but Safari would refuse to load/display the web page. Somehow other web pages in other tabs or windows would still work fine for a while… And then eventually the video freezes would extend to the entire interface, and I would have to go through the entire thing again.

When this particular version of the problem occurred, it jigged my memory, and I remembered something that I hadn’t thought about in a while, which was that I had noticed a similar problem (web pages failing to load for no apparent reason) long before I started experiencing the video freezes affecting the entire user interface for extended periods. It had been fairly rare, and at the time, I had not tried to troubleshoot the problem, precisely because it was fairly rare and I had simply filed it under the “General Crappiness of Apple Software These Days” category (subcategory: “Impossible-to-Reproduce Crappy Software Problems for Which Bug Reporting Would Be a Waste of Time”).

But now, this new episode led me to think that, maybe, just maybe, the video freezes that I had been experiencing lately were just a more severe and intrusive manifestation of a long-standing problem… which in turn led me to think that, maybe, just maybe, it wasn’t a hardware problem after all.

I obviously couldn’t know for sure, but the theory that the video freezes were a software problem was worth revisiting…

But what could I do about it if it was a software problem? Well, I was still running El Capitan at the time, because my experience with early versions of Yosemite back in 2015 had made me extremely wary of being an early adopter of major system upgrades. My original plan had been to wait until version 10.12.3 of Sierra before trying it on my Mac Pro. Sierra was currently at 10.2.2. What if I took the chance and tried to install Sierra on my Mac Pro now, in order to see if, by any chance, the upgrade might, inadvertently or not, contain a fix for the video freezes?

I figured that I didn’t have too much to lose at that stage, and that if I didn’t do it now, there was a good chance that Apple’s representatives would ask me to try to do that anyway as part of the process of further troubleshooting the freezes.

So I took all the usual precautions (full backup, application upgrades that hadn’t been done yet, reading about potential problems with Sierra) and then I took the plunge, on December 26.

Well, today is January 21, and I am happy to report that I have not experienced a single recurrence of the video freezes accompanied by the “stalling for detach” error messages in the system log.

So it looks like Sierra (at least version 10.12.2) does contain a fix for the problem. As you can imagine, it’s a huge relief for me. I don’t have to go through the time-consuming process of trying to get Apple representatives to acknowledge the seriousness of the situation and provide me with a solution. I have a computer that works well again, and does not have a hardware flaw after all.

There is an epilogue to this story, however. Since December 26, I have heard from a fellow Twitter user who has been experiencing similar problems, albeit on a completely different machine (a MacBook Pro). She too has been experiencing video freezes, along with “stalling for detach” error messages in the system log. (In fact, it’s through a Google search for this phrase that she found my blog post about my problem.)

In her case, her MacBook Pro has video freezes and displays the following message in the log:

stalling for detach from AMDVerdeGraphicsAccelerator

Same message with a different flavour of graphics accelerator… We now had a clearly strong sign that the problem was indeed software and not hardware. (In retrospect, the very fact that the freezes were accompanied by error messages in the log was a sign that it was a software problem. Hardware problems typically occur at a level that the system is not even aware of, and cause freezes or kernel panics without a trace of the reason why in the logs.)

Still, like me, she was told by Apple that her video card might need to be replaced. She had just got it replaced, and based on my experience, I now warned her that there was a good chance that it wouldn’t fix the problem. Sure enough, two days later, she had more video freezes.

I told her that I had upgraded to Sierra and that it seemed to have fixed the problem, but that it was still too soon for me to tell for sure. (Now that nearly a month has elapsed, I am quite sure.)

She decided to stick with El Capitan for a while, because she was wary of the PDF-related issues reported with Sierra. (To be honest, the reports of bugs with Preview had also worried me quite a bit before then. However, while I do use PDFs in my work quite a bit, I haven’t really noticed any significant problems in my workflow with Sierra yet, and I have been back at work for two weeks now. Of course, your mileage may vary…)

And then…

On January 17, Apple released an updated version of Security Update 2016-003 for El Capitan, dubbed “Security Update 2016-003 Supplemental”. And guess what? The release notes indicated that the update to the update addressed “a kernel issue that could cause a Mac running El Capitan to occasionally freeze and become unresponsive”. Mmm…

Of course, when my own video freezes started getting serious, in November 2016, I did wonder whether any recent system update might have been the culprit. But the only update that I had installed during that time was an early build of that very security update, which I got as part of my involvement in the Apple Seed program. And since it was “only” a security update, and since my problem clearly seemed to be a video problem, I figured that there was no way that the two were linked. (I actually remember mentioning that update to the Apple senior representative who had taken care of me in December. He didn’t think there was a connection either.)

Now, of course, in light of these new developments, I do have to wonder whether my own video problems were not caused by that update. The timing seems to confirm it, except for the fact that I do remember experiencing the occasional blank page in Safari long before last fall… Still, it is also possible that there was an underlying problem before the security update, but that the security update just made it way, way worse, at least for some Macs.

Also, when you look at the details about the security update that Apple provides on this page, you can see that it contains fixes for security bugs that do involve things like “AppleGraphicsPowerManagement”, “CoreGraphics”, and “CoreMedia External Displays”. So it is not too far-fetched to think that the security update might have introduced (or amplified) low-level issues that did involve the video part of the system.

My Twitter friend has now installed the Supplemental version of the security update and, so far, she hasn’t experienced any further problems. It’s probably still a bit too soon to tell for sure. (I’d give it a whole month myself to be certain.) But it now appears quite likely that the video freezes that we both experienced, accompanied with these “stalling for detach” error messages in the system log, were not hardware problems, and were indeed either caused or made much worse by the original version of Security Update 2016-003, and that Security Update 2016-003 Supplemental does fix them.

Still, both she and I had to go through the process of dealing with (relatively) clueless Apple representatives and had to waste time getting our computers serviced for nothing. We might have got brand-new video cards out of the deal, but that does not, of course, compensate for all the grief caused by the bug.

And, as usual, I cannot help but wonder whether there is really nothing that Apple can do to improve its process for dealing with serious bugs. If this problem was indeed caused by Security Update 2016-003, why were the Apple representatives that we dealt with not aware of it? Why did they instead suggest useless hardware repairs? And why was the bug fixed silently without telling us? Where is the knowledge base article on Apple’s web site that describes the problem that we experienced in full detail, with clear reference to the exact symptoms and to the “stalling for detach” error messages in the system log?

What if other people are still experiencing the exact same problem and are looking for help today? How will they know to install Security Update 2016-003 Supplemental, especially if they are inclined to avoid installing new updates right away, precisely because they don’t trust that Apple can produce bug-free updates in the first place?

Something is rotten here, and other reports online about this lack of transparency tend to confirm it. Apple needs to realize that bugs cost us time, therefore money, and that, unlike their own representatives and senior representatives, we don’t get paid for the time we spend trying to work around these bugs or get them fixed.

Will we ever get a new attitude at Apple that not only transparently communicates about such crucial bugs, but also apologizes for the significant inconvenience that they cause?


Fix for recurring Microsoft Word 2016 document opening/saving bug

Posted by Pierre Igot in: Microsoft
December 22nd, 2016 • 4:02 pm

Ever since I upgraded to Microsoft Office 2016 on my Mac, I have been experiencing this recurring bug.

Word 2016 works OK for many days. (I say “OK” and not “great” because Word never works great, even at the best of times.)

Then all of a sudden, for no apparent reason, it becomes unable to open or save documents. The application starts displaying all kinds of error messages, like the following:

word2016-cantopen

Alternatively, if you are in the process of working on an existing document that you’ve been saving regularly using Command-S until now, all of a sudden Word starts complaining that it can no longer save the document (which might leave you stranded if you made lots of changes since the last time you saved the document).

Sometimes, weird problems like this one can be remedied by quitting and relaunching Word. Not in this case, though. If you try to quit and relaunch Word, you then get the following message:

word2016-cantopentemplate

In other words, at this stage it looks like Microsoft Word 2016 has become unable to open any file, including its own Normal template file. To make matters even more scary, if you click on “OK” to continue and then try to quit Word the normal way, when trying to quit, Word displays the following error message:

word2016-cantopensavetemplate

Don’t click on “Yes”! (It won’t actually do anything, since Word is currently unable to open or save anything, but it’s still not a good idea.) If you click on “No”, Word still fails to quit. So at that stage the only option is to force-quit Word.

You can try this whole cycle multiple times just for fun if you want to, but whatever option you choose in those misleading error dialog boxes, nothing will work, and Word won’t go back to normal.

The whole problem happened to me again this afternoon. Normally, when it happens, I have found that the only solution was to reboot the entire computer. Today, however, I had a little time, so I decided to do more sleuthing.

My first reflex was to go to the Console and see if I could notice any error messages that might help better circumscribe the problem.

I first noticed that, even time I tried to relaunch Word, the system log would include something like this:

16-12-22 14:50:16,765 Microsoft Word[50336]: ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/sp/fgbr368s4_q5_rbzb_4k5w740000gn/T/com.microsoft.Word/com.microsoft.Word.savedState

So I figured that the problem might have to do with some kind of conflict between Word and OS X’s built-in application resuming feature, which normally causes an application to reopen the windows that were left open the last time the application was quit.

Of course, the irony here would be that OS X’s Resume (or “Persistence”) feature has never been supported by Microsoft. Word 2016 has never been able to reopen the windows that were left open the last time it was quit, even when the general setting in OS X’s System Preferences (under “General”) is as follows:

osx-resumesetting

Based on this message in the Console, Microsoft’s lack of support for this OS X feature clearly does not prevent OS X itself from trying to apply it to Word 2016, even if it does not do anything.

So my first troubleshooting step was to try and see if I should clear whatever “saved state” might linger in my system for Word 2016 and relaunch the application. I went to:

~/Library/Saved Application State/com.microsoft.Word.savedState/

and cleared everything inside that folder and tried to relaunch Word, but that didn’t work.

I then went to the exact location mentioned in that message in Console:

/var/folders/sp/fgbr368s4_q5_rbzb_4k5w740000gn/T/com.microsoft.Word/com.microsoft.Word.savedState/

and I cleared everything that was there and tried to relaunch Word, but that didn’t work either.

Finally, I tried to launch Word 2016 while holding the Shift key down. This did make a difference, in that Word 2016 no longer displayed the message saying that it was unable to open the Normal template. But that’s easily explained if you consider that starting Word up while holding the Shift key down effectively launches Word in a so-called “safe” state, for troubleshooting purposes. In that “safe” state, Word no longer tries to open the Normal template, in case the template itself is the source of whatever trouble you are trying to address. (It is not the source of the trouble in this case, which can be demonstrated by the fact that the whole situation is resolved by simply rebooting the entire system. After that, Word 2016 works fine again, with the same Normal template.)

After launching Word 2016 successfully in a “safe” state, however, I found that it was still unable to open files. So the problem was not fixed.

Basically, this whole process suggested that the problem had nothing to do with OS X’s Resume/Persistence feature and couldn’t be fixed by fiddling with the folders involved in that feature, and that the error message in the Console didn’t really mean anything significant. (I was able to confirm this later on by finding that the error message still appeared upon launching Word even when Word was working normally again.)

I then paid closer attention to the other references to Microsoft Word in the system log in the Console, and found multiple occurrences of another suspicious-looking message:

16-12-22 15:43:17,268 Microsoft Word[61532]: NSAllowAppKitWeakReferences=YES

I had no idea what it meant, but I decided to try and find out if anyone online had ever referred to this “NSAllowAppKitWeakReferences” variable in the context of troubleshooting Word 2016.

I first found a thread on Apple Discussions, but that thread discussed a different problem (Microsoft Error Reporting quitting unexpectedly) and nothing is the thread was helpful in my situation.

Then I found this thread on the Microsoft Community forum for Office 2016 for Mac. It contained lots of the usual bullshit about things being Apple’s fault, Microsoft allegedly having fixed (or not fixed) the problem, Microsoft allegedly having noted that multiple users were reporting the problem and being supposedly working on a solution, Microsoft not being involved in these “user-to-user” discussion forums even though a user named “Erik J” had “[MSFT]” appearing next to his name, etc.

And then I saw the very last message in the thread, from that Erik J who might or might not work for Microsoft, who mentioned the following troubleshooting steps:

  1. Close Word.
  2. Click the magnifying glass icon in the top right corner of your screen, type Terminal, and press Return.
  3. In the Terminal window that opens, type the following and press Return: defaults write com.microsoft.Word ForceTempFilesInAppContainer 1
  4. To ensure that this setting worked,
    • Open a Finder window, and press Command+Shift+G.
    • Type the following path: ~/Library/Containers/com.microsoft.Word/Data/Library/Application Support/Microsoft/Temp
    • Press Return. Upon launching Word, this folder will be created if it doesn’t exist, and Word will create a temp file inside it. Quitting Word will then cause this temp file to removed, which tells us that the new setting has taken effect.

I don’t really know what this does, but I tried it this afternoon on my machine after Word 2016 started acting up and refusing to open or save any file, and… it fixed the problem!

After typing the above-mentioned defaults command in Terminal and relaunching Word, I found that it was back to normal, able to open the Normal template without trouble and able to open and save files as expected.

Given that Erik J does not give any further information and that it is the last post in the thread (dated August 19, 2016), I don’t know if it’s a permanent fix or a temporary one, or if it’s even meant to be a fix. All I know is that it seems to work on my machine for my copy of Word 2016, and that this seems to indicate that, if the problem occurs again, I might be able to fix it without having to reboot my entire machine, which is of course a significant relief.

One ironic aspect of the whole process is that, after all this, I discovered that, even when Word 2016 was back to working normally again, it still caused the recurrence of the NSAllowAppKitWeakReferences=YES error in the system log. So maybe that error in itself doesn’t mean anything either, but actually just guided me to the right forum.

I will post a link to this blog post on the forum at the end of that discussion thread, and maybe Erik or someone else at Microsoft will notice it and maybe (yeah right) get back to me with a request for more information or a confirmation that this is a fix (and that it will be included in a future update). Whatever happens, I figure the most useful thing that I can do for fellow Word 2016 users is to write about the whole thing in a blog post, so there you are.


Video freezes on Mac Pro: Video card replacement required

Posted by Pierre Igot in: Macintosh
December 18th, 2016 • 5:19 pm

I don’t know it is bad luck or something else, but I have certainly experienced my share of hardware flaws and failures with Apple products over the years. I am not talking about more or less predictable failures here, like conventional hard drives failing after a few years, or power adapter cords becoming frayed (although I’ve certainly had my share of those as well, of course). No, I am talking about hardware issues that were due either to clear design flaws or to defective parts.

The first significant one that I can remember is the problem with wifi reception on the original Titanium PowerBook G4 back in 2001. (While this was never officially acknowledged, the titanium shell of the laptop effectively acted as some kind of Faraday cage and had a significantly detrimental effect on wifi reception on the laptop, which, as you can imagine, was a massive disappointment.)

Then, in 2003, I had a Power Mac G4 MDD that was affected by a major noise problem with its power supply unit. The problem was so bad that an online petition was started, and eventually Apple had to offer a replacement program for those affected.

That G4 MDD was replaced by a Power Mac G5 in 2005, and that machine worked well for a while, but then after less than a year I started experiencing all kinds of random freezes. Apple was never able to fix the problem, and eventually offered to replace it with a Mac Pro.

Meanwhile, in 2006, I also purchased a new black MacBook for my wife and, for the first time ever, I had to send the machine back and ask for a refund, because it had unacceptable noise issues that were treated by Apple as “normal” or “working as expected”.

In 2007, I ended up purchasing a 17″ MacBook Pro instead, and it worked OK for a while, and then the machine started developing a problem with a bulging battery.

Still in 2007, I started having kernel panics with my 2006 Mac Pro that required a logic board swap.

In 2009, I started experiencing kernel panics on my 2009 Mac Pro with dual video cards (to drive two monitors). These kernel panics were clearly due to a software issue, but since the software issue only affected a small subset of users (those with two video cards), Apple never did acknowledge it, and I ended up opting to purchase an expensive replacement video card of a different kind just to work around the problem.

That 2009 Mac Pro worked fine after that (and is, in fact, still going strong today in late 2016, with a third-party SSD as its system volume and with that replacement video card), but I eventually replaced it with a 2014 Mac Pro as my main work machine.

While I had major responsiveness issues with the 2014 Mac Pro when running the early versions of Yosemite (a very annoying software problem), I didn’t have any really significant hardware issues for the first couple of years. (This Mac has some occasional Thunderbolt-related glitches, and there is also a noticeable high-pitched whine at times when the machine is running a bit hot, but these are relatively minor.)

Then, a few weeks ago, I started experiencing something new. For no apparent reason, out of the blue, the Mac Pro started experiencing video freezes. During these freezes, everything on the screen would be completely frozen except for the mouse pointer, which would continue to move normally, although nothing would respond to mouse clicks. Sometimes, the mouse pointer would eventually turn into the Spinning Beach Ball of Death and nothing would happen for several minutes, so I would end up forcing a hard reboot, by holding the Mac Pro’s power button down for five seconds.

Most often, however, each freeze would last about 20 or 30 seconds, and then things would become responsive again, but only for a few seconds. OS X would try to execute some of the mouse actions that I had attempted while the screen was in the process of becoming frozen (which had obviously been stored in a buffer by the system), but then after a few seconds, everything would freeze again. The same cycle would repeat a few times, and then eventually things would go back to normal.

In addition, sometimes, at the same time the screen would freeze, I would see some video corruption, typically in some part of the main Mail Viewer window in Mail:

2014macpro-videocorruption

Like the freezes, the corruption would eventually clear up.

Luckily, this problem happened at a time when I hadn’t done any significant system updates in a while, except for a security update for El Capitan. So I was able to relatively easily rule out a software problem. (I still did suspect the security update for a while, although it was very unlikely, because I am still part of the AppleSeed program, and had installed early builds of it before the final, official release.)

From the very beginning, my 30 years of experience troubleshooting Mac computers for myself and for clients suggested to me that this was a hardware issue. I still went through all kinds of routine troubleshooting steps (zapping the PRAM, emptying caches, etc.), especially since, at the beginning, it looked like the problem would typically happen right when I would attempt to load a graphics-rich web page in Safari.

Of course, the problem was intermittent and impossible to reproduce reliably. It would just happen seemingly randomly. Sometimes I would go a couple of days without a single freeze. Sometimes I would get two or three freezes in a single day. It didn’t seem connected to what I was doing at the time either, except for the fact that it most often occurred while browsing the web with Safari (a very common activity, of course).

I tried to run the Mac Pro’s hardware test from the recovery partition, but the test failed to identify any issue (which didn’t prove anything, since the problem was very intermittent).

I ended up getting on the phone with AppleCare. (I had purchased the three-year warranty for the Mac Pro back in July 2014, so it was still covered.) The phone representative was relatively competent and made me execute a few typical troubleshooting steps, including some that I had already done and some that I had not. She said to give it a try and get back to them if it didn’t solve the problem.

It didn’t. I did some more research and found that the system log in Console would, around the times of the freezes, contain multiple occurrences of an error message looking like this:

Mac-Pro kernel[0]: stalling for detach from AMDTahitiGraphicsAccelerator

I tried to find references to this online and was not very successful. But I did find this thread on the MacRumors forums, which appeared to confirm that this kind of problem was either with the GPU driver software or with the GPU cards themselves. (I also tried some low-tech troubleshooting steps, like trying to get rid of whatever dust might have accumulated inside the Mac Pro, and also switching Thunderbolt cables around, in case the problem was some kind of weird glitch with the video signal over Thunderbolt. Nothing helped.)

After a few days, I was on the phone again, and this time I didn’t have too much trouble getting the person to understand that I knew what I was talking about and that I had effectively “done my homework”. I told her quite bluntly that a trip to the Apple Store would be a four-hour round trip for me and that I hoped she would try and minimize the need for such trips, by ensuring that they were as useful and constructive possible.

Still, she couldn’t guarantee that the Apple Store folks in Halifax (Nova Scotia) would readily accept my request to swap the graphics cards. All she could do was to set up an appointment so that I could bring my machine to someone at the “Genius Bar” and get them to have a look at things.

With winter and nasty, unpredictable weather approaching, I took the next available appointment, which a few days later, on a Tuesday, at 10:40 am.

I arrived on time for the appointment, but the “Genius Bar” was obviously very busy with all kinds of folks getting one-on-one lessons on fairly straightforward stuff (as far as I could tell from the conversations I overheard). I had to wait for about 10 minutes, and then finally got to talk to someone about my problem. To her credit, she quickly realized that the issue was beyond her level of expertise and she summoned someone in the back, who showed up after a few more minutes.

He seemed to know his stuff, and proceeded to run a number of more “advanced” tests. Fortunately for me, he quickly noticed something odd, which had nothing to do with what I was experiencing: Whenever he tried to run his special testing software, the whole screen would take on a purple tinge. He asked me if I had ever noticed such a purple tinge while running the Mac Pro. I told him that I had not. But he was definitely able to reproduce this (and not my freezes) reliably while running his tests and this, to him, was reason enough to initiate a repair process that would involve ordering two replacement video cards and a replacement logic board (since he said the graphics problem could be located at the site of the connection between the video cards and the logic board).

They would have to order the parts and then try them in the machine to see if it made any difference (to the purple tinge problem, obviously). He said the whole process should take three to five days.

Unfortunately, since I only had consumer-level warranty coverage, my only option was to either go home with my Mac Pro and continue to use it for a few days, then come back in when the parts were in and leave the Mac Pro with them for who knows how long. I didn’t exactly relish the prospect of multiple round trips to Halifax, especially because of weather issues and also because of the typical shopping rush before the holidays.

Then I had to make a quick decision. I thought that my wife was currently still using my 2009 Mac Pro, which would turn eight years old in a few months. As I said, that 2009 Mac Pro with an SSD (bought from Other World Computing several years ago, and actually replaced once under warranty since the original purchase) and with a replacement video card was still working fine, but there was no denying that it was getting old. Also, my wife never liked the fact that she had to deal with a big tower, which was, of course, too powerful for her needs and, most important, rather noisy (relatively speaking) for her home office environment. So I figured that now was as good a time as any to replace her own computer with a more recent Mac, and the obvious (albeit rather expensive) option was to get her a 27″ iMac 5K. Provided that they had one in stock, I would leave the Mac Pro at the Apple Store and use that new iMac 5K as a replacement for my work machine until the repair was complete.

Granted, the iMac 5K model itself had not been upgraded by Apple in a year, and I would be spending a significant amount of cash on a model that was not exactly brand new and didn’t have the very latest technology (USB-C/Thunderbolt 3, etc.). But my wife didn’t really need the very latest technology and, besides, my experience as an early adopter (of both hardware and software) in the past 15 years has been decidedly mixed. It would also give me a real chance to put the iMac 5K to the test in my own work environment, to see if it might ever be considered as a potential replacement for my 2014 Mac Pro (given that the Mac Pro has been completely neglected since 2013 and that there is sadly a real chance that it will eventually be discontinued altogether).

The Halifax Apple Store did have the 27″ iMac 5K in stock, but only with Fusion drives (an SSD-only iMac can only be had through the built-to-order process) and only with 8 GB of RAM. I asked if they could at least upgrade the iMac to 16 GB, and they were able to do that in under an hour. So we left my Mac Pro at the Apple Store and went home with a new 27″ iMac 5K with 16 GB of RAM and a 2 TB Fusion drive.

For the next 24 hours or so, I attempted to use the iMac as my work machine without restoring my full work environment from my backup, by only installing what I thought I really needed, since it was only for a few days. That was a mistake. My work environment is heavily customized, with tools such as Typinator, Keyboard Maestro, LaunchBar, and so on. In addition, some other tools that I use on a regular basis, like the Grand Robert French dictionary on CD-ROM, are very poorly supported by the developer, and I soon found that, while the CD-ROM still works fine in my customized work environment, I couldn’t get it to work in a brand new environment. (The software would crash every time I would attempt to “authenticate” it by inserting the original CD-ROM. There was no hope of getting any help from the developer on a timely basis.)

So I ended up restoring my work environment from the backup just the same, even though it was a backup of the startup volume for my Mac Pro, and not of a startup volume for an iMac. The process took a while, and there was a scary moment at the end, when I attempted to boot the iMac from the restored work environment and I just got a black screen. I managed to solve the problem by rebooting with the Shift key down, forcing the iMac to start in Safe Mode and, while that was quite slow, it did work, and after that I was able to boot normally.

I was pleasantly surprised to find that the iMac was perfectly able to drive both its internal 5K display and my external 4K monitor as a main display via Thunderbolt. This meant that it was relatively easy for me to restore a fully functional work environment with two displays, the iMac effectively replacing my second (and older) 30″ Cinema HD display. (Even my Keyboard Maestro macros for moving windows from screen to screen still worked, because the “virtual” resolution of the 5K display obviously matched the normal resolution of my older 30″ display.)

And I must admit that I was more than pleasantly surprised by the quality of the 5K display itself. Now that I have experienced it, I can say without any reservations that my dream work environment right now would be to have a new Mac Pro that is able to drive two large 5K displays side by side. Sadly, such a machine does not exist, and we might have to settle for an improved iMac 5K that is able to drive one or two external 5K displays — if such a machine ever gets made.

I have no idea whether Apple is slowly abandoning its desktop computer lineup or not. It certainly feels that way these days. Needless to say, it would be news of catastrophic proportions for us professional users. The irony would be that it would happen just as the hardware capabilities in the industry are finally getting where we want them to be (i.e. affordable computers able to drive multiple affordable 5K screens).

The other concern I had about the iMac on my desktop was about the noise. The Mac Pro is near silent (except for that occasional high-pitched whine) and all my conventional storage (with hard drives) is in another room, with a 30-ft optical Thunderbolt connection through the wall. The iMac on my desktop brought a conventional hard drive (the conventional part of the Fusion drive) back within earshot. The noise was definitely noticeable, but I must admit it wasn’t really significant.

Of course, I didn’t really try to do anything hardcore, like exploiting the computer’s multiple cores to encode a large video file, for instance. So I don’t really know how noisy the iMac 5K can get. But I do know now that, under regular circumstances, doing the stuff that I regularly do, the noise level remains low and is quite acceptable. It’s not perfectly silent, but then nothing really is. It is very quiet, and if I had to choose between this constant low-grade white noise and the occasional whine coming from my Mac Pro, I am honestly not sure which I would choose.

So, I did eventually manage to work with the iMac as my main work machine for a few days, and, on the fourth day (a Saturday), I got a call, around… 8 pm, from the Apple Store, letting me know that they had swapped one of the video cards, and that the problem, as far as they were concerned, appeared to be fixed (which, presumably, meant that the purple tinge was gone).

I knew that a friend of mine was going to Halifax the next day, and he had already offered to pick the machine up for me if it was ready. So I told the Apple Store representative on the phone about this, and he said that it wasn’t a problem, that I could just give him my friend’s name and he would add it to the file as a person authorized to pick up the computer on my behalf.

The next day (Sunday), I got another call from the Apple Store, telling me that they had someone there to pick up my computer, and… that person was not authorized. With all the high tech that they have for managing their support calls and repair jobs, they obviously still are vulnerable to human error, or whatever the reason for this mix-up was. In any case, I repeated the name again, and it was OK.

My Mac Pro was back at home later in the evening, and I set things up again the following day. Everything was in working order, and I just had a backlog of a few days of daily tasks (filing emails away, transferring newer files, etc.) to complete before I was fully back in business.

I didn’t get any video freezes on that first day, but I figured I’d better wait for a few days at least before drawing any conclusions. It’s now been seven days, and I still haven’t had a freeze. I have also checked that there is no longer any occurrence of the “stalling for detach from AMDTahitiGraphicsAccelerator” message in the system logs.

So currently the signs are good that whatever problem in the video card caused the freezes was also what caused the purple tinge, and that fixing one fixed the other. After all this, I guess I can count myself lucky that my intermittent freezing problem also happened to have a non-intermittent side effect, which conveniently made the issue obvious and undeniable to Apple’s technicians.

Overall, I must admit that my experience with the Apple Store in Halifax for this repair was good. If I hadn’t purchased the extended AppleCare warranty back in 2014, the repair would have cost me nearly $400. With the warranty, it cost me nothing except the time wasted trying to troubleshoot the problem and then dealing with the Apple Store and travelling there to get the problem looked after. (I am obviously not counting the purchase of the iMac 5K here, but I must admit things would have been significantly more complicated for me and my work if I hadn’t seized this opportunity to replace my wife’s aging computer.)

I just have one last observation to make about the Apple Store staff. Everyone on the floor in the store does everything on iOS devices (iPhones, iPads): look up information, process payments, record data, etc. I was quite impressed with the staff’s typing skills on their iOS devices, which were obviously much better than mine (with far fewer typing mistakes, as far I could tell).

However, I couldn’t help but notice that, when using iOS for things other than typing, like tapping on buttons, links, etc., even with all their obvious experience using these devices, they still very often have to tap on buttons twice or even three times (or even more times) to get the buttons to respond to their taps. This definitely matches my experience, and I was secretly pleased to observe that I am not the only one, and that even experienced users have this problem.

I realize that the mouse is not a perfect pointing device either and that there is a small percentage of missed clicks, missed UI targets, etc. But as far as I am concerned (and, based on my observation, as far as a lot of users are concerned, even experienced ones), the percentage of misses is nowhere near as high as it is with tapping on buttons on a touch screen. Based on this observation alone, I simply don’t see how anyone can argue that a touch screen is an appropriate interface for doing serious work. The rate of wasteful tactile interactions is just far too great. (I have little experience with trackpads, but I suspect that they would fall somewhere in between a mouse and a touch screen when it comes to the error rates.)

And let’s not even discuss the replacement of real keyboard keys with “virtual” keys on a miniature touch screen… How often does a press on a keyboard key actual fail, as opposed to a tap on a button on a touch screen?

I don’t really know what to think (the worst?) of recent developments when it comes to Apple’s desktop hardware. But I won’t deny that I am quite worried about the long-term future of my use of a Mac computer with two large screens for my work. Will it at least remain viable until I retire (which is not for another 15 years or so!)? I tried to share my concerns as a “business” user with the Apple Store staff in Halifax, who, of course, are quite interested in trying to sell me more “business” products and services, but unfortunately that didn’t get very far

However, at least now I know that, in the immediate future, if worse comes to worst, I do have the option of replacing my Mac Pro with an iMac 5K. It wouldn’t be ideal and I would still be disappointed, but I could make it work. So that, at least, is partly reassuring.


OS X 10.11 (El Capitan): New mouse-related bugs

Posted by Pierre Igot in: Macintosh
July 23rd, 2016 • 5:53 pm

One of the very few new features that I was (moderately) excited about when I upgraded to OS X 10.11 (El Capitan) was the “Shake mouse pointer to locate” option in System Preferences > Accessibility > Display:

elcapitan-cursorshake

After a few months with El Capitan, I can now report, with relatively conclusive evidence, that once again, Apple has proven incapable of introducing a new (and potentially useful) feature without introducing all kinds of new bugs at the same time. (Does this remind you of anyone?)

As soon as I upgraded my 2014 Mac Pro to El Capitan, I noticed the following problem. Occasionally, when waking my computer from sleep in the morning, I would be faced with a user environment with no mouse pointer anywhere on the screen. No amount of mouse shaking or fiddling with the keyboard (which seemed to work as expected) would bring it back. The only solution was to unplug the mouse (I still use a old, wired Apple “Magic Mouse”), wait a few seconds, and then plug it back in. Then the mouse pointer would finally magically reappear.

I upgraded to El Capitan back when the 10.11.3 update came out. We are now at 10.11.6 and nothing has changed. The problem still occurs from time to time. Of course, it can’t be reproduced reliably 100% of the time using a specific sequence of steps, so there’s basically no point in even trying to report the bug to Apple. Even if someone over there did care, they would never have the chance to devote time and resources to trying to reproduce the problem themselves and then doing something about it. It simply is not the way it works with Apple. Either you have a 100% reproducible scenario, preferably for a bug that affects lots of people, or you’re out of luck and trying to get the bug acknowledged and fixed is an exercice in futility.

Last week, several months after upgrading my own Mac, I took the time to upgrade my wife’s Mac, which is a 2006 Mac Pro tower — an old machine, I know, but one that has been upgraded with a faster video card and with a solid-state drive. That Mac Pro still works fine, and still supports the latest system, so we have little incentive to replace it with something more current. But… that also means that we are now more likely to encounter new bugs with more recent versions of the system that Apple doesn’t know anything about and doesn’t care about, because there are now too few users running the OS on such old machines, and because they probably don’t do any testing in-house whatsoever on such old machines themselves.

Guess what? As soon as I upgraded her Mac to El Capitan, I noticed another mouse-related problem.

On her Mac, the problem is the following. Every time the Mac Pro (the entire machine, not just the screen) goes to sleep, when I wake it up, things seem to be working OK, but then after a few seconds the mouse pointer freezes completely. The Mac continues to respond to keyboard input. (Application-switching with command-Tab still works, for example.) But the mouse pointer itself refuses to move, and some other UI events seem to be stuck. Then after twenty seconds or so, El Capitan snaps out of it, the mouse pointer starts responding to mouse movements again, and other UI events stuck in a queue (system beeps, notifications) are spurted out in rapid succession.

Things work fine after that, but whenever the Mac Pro is put to sleep, either manually via the Apple menu or because of its Energy Saver settings, the same problem occurs a few seconds after waking the machine from sleep.

This time, the problem is 100% reproducible. I have even been able to reproduce it in a separate user environment with no customizations. So I could report it to Apple. But do I really think it’s worth the effort? I am far from convinced. Even if someone did pay attention to such a bug report, the likelihood of the bug getting fixed would be very small. (I’ve searched through the forums, and I haven’t found too many reports of the exact same problem. People have other freezing problems, but they are not temporary, and they don’t occur a few seconds after waking the Mac.)

So, what’s the solution? I can either ask my wife to get used to the 20-second delay every time the machine wakes from sleep, or I can change the Energy Saver settings so that the machine itself never goes to sleep. I can still get the screen to go to sleep and the hard drives to go to sleep, but I can set the Mac itself to “Never”. Of course, the environmentalist in me is not too happy about this, because it means more energy wasted for no reason (and also possibly a shorter lifespan for the machine). But what else can I do, really? I don’t get any sense that Apple really cares about such issues anymore (if they ever did).

The environmentalist in me is doubly annoyed these days, because my own 2014 Mac Pro also has a power-related problem in El Capitan. It now refuses to go to sleep altogether, even when I ask it to. It does go to some kind of semi-sleep, as evidenced by the fact that it stops checking for new mail after a while (even though I do have enabled Power Nap, for whatever that is worth), but the Mac itself never switches to the low-power mode with the pulsating light and zero fan noise. It stays on, and so does my external Thunderbolt enclosure of conventional hard drives in the basement.

This particular problem was introduced in the 10.11.5 update and is still there in 10.11.6. Earlier versions of El Capitan had no problem letting the Mac Pro go to sleep (and the Thunderbolt unit would automatically go to sleep itself after a few moments). I have reported the bug to Apple, and they have responded, by asking me if I can still reproduce the problem… in Developer Preview 3 of macOS Sierra! Really helpful… I guess there’s no hope of that one getting fixed any time soon either, then.

And up goes the wasteful power consumption in the Igot household thanks to Apple bugs…

I don’t believe this last bug has anything to do with the mouse, but I thought I’d mention it as yet another example of new, annoying bugs creeping up all the time in Apple software these days.

That is not all, however, as far as the mouse is concerned in El Capitan on my Mac Pro. By far the worst problem is another one, which I will attempt to describe now.

From time to time, seemingly out of the blue, the movements of the mouse pointer on my screen start getting jumpy. That’s the best way I can describe it. I move the mouse in a straight line, either dragging something along or just to click on something, and in the middle of the straight line, all of a sudden, the mouse pointer jumps to a different location on the screen.

It is very discombobulating and of course, causes me to make all kinds of errors, by clicking on the wrong target or dropping something in the wrong place. And it seems to be random.

I have been able to capture an example of the behaviour with ScreenFlow, which you can view in the following video clips. (The clips are in my Dropbox folder. You can preview them on the web or download them to play them on your desktop.)

To begin with, here’s a video clip of me dragging a window up and down in the Finder with smooth, responsive movements:

ElCapitan-NOTJumpy.mp4

Now here’s a nearly identical video clip, but this time with some “jumpiness” in the mouse movements:


ElCapitan-Jumpy.mp4

Hopefully you’ll notice the difference. In this particular clip, the jumps in question occur when going back up with the mouse.

This is just one particular example. The jumps are totally random and are sometimes much more significant, which makes it all the harder to keep track of the mouse pointer’s position.

Unfortunately, once this starts happening on my Mac Pro, the only way I have found to make it stop is to reboot the entire system — which, as you can imagine, is a major pain in the neck.

I haven’t really found much help through online searches. All I know is that the problem started occurring as soon as I upgraded to El Capitan. It cannot be a coincidence!

At some point, I suspected Bluetooth, but I don’t use any Bluetooth devices. Indeed, the upgrade to El Capitan, the system unilaterally reactivated Bluetooth on my Mac Pro, so I had to manually turn it off again. And for a while I didn’t have the jumpiness problem. But then it started happening again, even with Bluetooth off. So that wasn’t the culprit.

I am still investigating (and rebooting when I need to get work done). Right now I am experimenting with turning the “Shake mouse pointer to locate” option off altogether — even though I actually find it somewhat useful. (I have two large screens. Add to that the fact that Apple still has not fixed the on-going problem with the mouse pointer not changing reliably depending on the context, as it’s supposed to, and you can easily end up with the wrong mouse pointer on a background that makes it very hard to see.)

Of course, I cannot say with 100% certainty that this new problem is directly linked to the introduction of the the “Shake mouse pointer to locate” option in El Capitan. But I cannot help but wonder… and despair, once more, of Apple ever getting its house in order and shipping an OS that actually fixes a whole whack of bugs without introducing a whole whack of new ones.

Fun times…


OS X 10.11 (El Capitan): Problem with vanishing keystrokes still not solved

Posted by Pierre Igot in: Macintosh
May 24th, 2016 • 1:35 pm

In March, I wrote about my experience with OS X 10.11 (El Capitan), in relatively glowing terms. After my nightmarish experience with OS X 10.10 (Yosemite), the relatively smooth upgrade to El Capitan and the significant improvements in responsiveness were like a breath of fresh air. I even found long-standing bugs that were significant for me and that had finally been fixed…

Now that a few months have elapsed, however, I am afraid I need to revise my judgement somewhat. El Capitan is still a vast improvement over Yosemite, but I can now report that there are significant issues with OS X that were introduced several years ago (the consensus being that many of them first appeared in Lion) and are still not fixed in El Capitan.

First and foremost, there is still a major issue with keystrokes disappearing into the ether. I first reported on such a problem in OS X’s Mail back when Lion came out, in 2012. Since then, in every single version of OS X that I have used, I have noticed the problem, not just in Mail, but in various other applications, both Apple applications and third-party applications. It is, of course, an intermittent problem that is, for the most part, impossible to reproduce reliably.

I recently wrote a post about a particular scenario in OS X’s Finder where I can reproduce the problem 100% reliably. But this is just a particular scenario. There are many other scenarios (composing messages in Mail, writing texts in Word 2016 or Nisus Writer Pro, etc.) where the problem with disappearing keystrokes occurs randomly and unpredictably. It’s like OS X suffers from responsiveness “hiccups”, and these hiccups are enough to cause it to lose track of what’s currently being typed by the user.

The feedback I got after writing that post was that it probably had something to do with OS X handling stuff “asynchronously”… I am afraid I don’t know enough about the innards of OS X to understand what’s going on here. All I know is that responsiveness problems in OS X are nothing new and that, in the past, as far as I can remember, OS X always seemed to have some kind of internal buffer that would prevent it from losing track of what was being typed. Yes, the flow of text being typed out would sometimes be interrupted by hiccups, but these hiccups wouldn’t actually cause OS X to lose keystrokes. They would be processed eventually, after the hiccups had passed.

Now, since Lion at least, OS X basically has hiccups that not only slow you down, but actually can cause some of your keystrokes to disappear altogether without bring processed. How is this acceptable?

As usual, problems in OS X manifest themselves in clusters, and there is no denying that the problem with lost keystrokes tends to be worse in applications that also have their own responsiveness issues, most notably in Word 2016. This effectively makes Word, an application that is already of very poor quality to begin with, even worse. The problem with vanishing keystrokes also tends to get worse overall when there are several background processes that are taking place, and actually slowing down the entire system for obvious (and understandable) reasons.

But let me be clear about this: The hiccups and the vanishing keystrokes can only happen in OS X even when there is no obvious reason for the system to become less responsive, even only temporarily. My system is complex enough that I cannot fully know, at any given time, exactly everything that is taking place, but I always keep an eye on CPU levels on my Mac, and the hiccups and the vanishing keystrokes can happen even when CPU levels are quite low and there is no apparent reason for my machine to experience a slow-down.

Worse still: The hiccups don’t just affect text entry. If a hiccup occurs while I am in the process of typing a sequence of keystrokes to execute a series of actions, i.e. a sequence of keyboard shortcuts in an application, it can actually affect the execution of the actions. And of course, unlike text entry, which is visible on the screen, missing keystrokes in sequences of keyboard shortcuts are not easy to spot. It can be rather maddening!

I find it rather sad that, in 2016, on a very powerful machine (a 2014 Mac Pro), I find myself having to monitor activity levels on a regular basis just in order to try and better understand why my system is not more responsive or in danger of losing some of my keystrokes, and adjust my own behaviour accordingly.

When exactly will Apple finally produce a computer that does not force fast users like me to wait or adjust their own speed? As I said, overall, El Capitan is indeed much more responsive than Yosemite, at least on my 2014 Mac Pro, with the same array of both Apple and third-party applications that I use on any given day. But it still isn’t as good as a system such as OS X Snow Leopard used to be, and one of the main reasons is that responsiveness issues (which have always been a fact of life in OS X) are now compounded by the very serious problem of randomly vanishing keystrokes.

I would probably be much more tolerant of hiccups if they didn’t cause keystrokes to disappear. I would be able to simply ignore the hiccups then. But as it is, I cannot help but notice them, because whenever they happen, there is a risk that I might lose keystrokes and have to retype, in part or in full, what I have just typed all over again.

Am I really the only one who’s bothered by this?

(Things can get even worse. From time to time, I experience a hiccup that is so bad that it causes the foreground application to somehow “seize up” completely when it comes to keyboard input. When that happens, even though the application itself remains responsive — I can still navigate its menus, dialog boxes, etc. — it refuses to process keyboard input, instead playing a system beep or doing nothing. When that happens, things don’t get back to normal by themselves. I have no choice but to quit and relaunch the application altogether. You won’t be surprised to hear that the application most often affected by this is Microsoft Word 2016, but I believe I remember experiencing the problem in other applications as well, even if it’s much rarer.)


OS X 10.11 (El Capitan): Finder fails to record first few keystrokes typed immediately after creating new folder

Posted by Pierre Igot in: Macintosh
March 26th, 2016 • 2:33 pm

Last week, I wrote about how pleased I was with my upgrade from Yosemite to El Capitan.

I am still pleased, but daily use of El Capitan is starting to reveal things that I hadn’t noticed in my first few days of playing with the new OS.

As I noted in my post, I am a fast user. Yosemite was very frustrating because of all kinds of small responsiveness issues that caused it to experience “hiccups” and to fail to register some of my keystrokes or mouse clicks if I went “too fast” for it.

El Capitan’s responsiveness is much better. However, it’s not perfect. And I have a very simple example of a very common situation where, like its immediate predecessor, it fails miserably.

In OS X’s Finder, when I want to create a new folder, I tend to use the keyboard shortcut, i.e. command-shift-N. This is supposed to create the new folder and then make its default name (“untitled folder”) editable and highlighted, so that I can start typing the new name over the default name right away.

The key problem here is what “right away” actually means. In my mind, it means what it means in everyday English, i.e. without any delay.

In OS X 10.11, however, it means something else. It means “very soon after pressing command-shift-N, provided you give OS X a little time to recover from the tremendous strain of having to create a new folder and make its name editable and highlighted”.

In practical terms, it means that, after I press command-shift-N on my machine (a 2014 Mac Pro with 32 GB of RAM, with a 1 TB SSD as the startup volume), I cannot start typing the name right away. I have to wait for a fraction of a second before I do so. If I don’t, then the first couple of letters I type fail to appear in the folder name that I typed.

Yes, you read this right: I, Pierre Igot, am a supernaturally fast typist, with whom a powerful machine such as the 2014 Mac Pro is not able to keep up.

I am joking, of course. There’s nothing supernatural about my typing, and I am quite sure the Mac Pro itself is not at fault. The problem is, as usual, with Apple’s software and, in this particular case, with El Capitan’s Finder.

I’ve actually created a very simple Keyboard Maestro macro to reproduce the problem:

ElCapitan-Finder-NewFolder1

This macro does exact the same thing I do when I create a folder and type its name (“My new folder name” in this example), except, of course, that the macro is executed by the Keyboard Maestro engine, which is much faster than I, lowly human, can ever hope to be.

And guess what? El Capitan’s Finder completely fails to record the entire typed text. When I execute this macro on my Mac Pro, all I get is a new folder titled “untitled folder”. There’s no sign of the typed text (“My new folder name”) that the macro has input as typed text.

After experimenting a bit, I have found that, in order for El Capitan’s Finder not to ignore the typed text, there needs to be a pause of at least 0.3 second between the first step (the creating of the folder) and the second step (the typing of the folder name):

ElCapitan-Finder-NewFolder2

With that pause, everything works fine. If I only put a pause of 0.2 second, I get a folder with the truncated name “older name”. And if I only put a pause of 0.1 second, I get… nothing.

Of course, my own human hands are totally incapable of typing this fast, and in reality, when I execute these steps manually in El Capitan’s Finder, the worst that happens to me is that I am missing the very first letter of the name that I typed. But it happens often enough that it is very frustrating, especially since I only notice it once I’ve typed the rest of the name, and so I have to backtrack and edit the name manually in order to restore the missing letter at the beginning of the folder name.

What is really unbelievable to me here is not so much that the Finder needs a fraction of a second after creating the folder. It is that there does not seem to be any kind of text input buffer that keeps my keystrokes in memory until the OS is ready to process them. The keystroke(s) that the Finder fails to register simply disappear into the ether, as if the characters had never been typed.

How on earth is this acceptable in a modern operating system? It’s one thing to have speed/responsiveness issues. It’s quite another to fail to include standard features such as a keyboard buffer in order to minimize the impact of such issues on the actual usability of the software.

Last week, I was tempted to call El Capitan the best OS X release in a long time. It still is way better than Yosemite, and probably also better than Mavericks, Mountain Lion, and Lion. But beyond that? I don’t remember having basic keyboard buffer issues in the old days of OS X. What the hell is going at Apple? In the rush to add new features and simplify computing for the masses, have they somehow completely forgotten the basics?

Two words, Apple: Keyboard. Buffer.

It is that simple.

PS: If you are as bothered by this as I am, please report (rdar://25375085).

UPDATE: BR closed by Apple as duplicate of BR #23108215 on 2016-04-12.


My experience with OS X 10.11 (El Capitan) on my 2014 Mac Pro

Posted by Pierre Igot in: Anti-Aliasing Hall of Shame, Macintosh, Mail, Microsoft, Technology
March 18th, 2016 • 6:16 pm

I haven’t written on this blog since last year and my very traumatic experience with upgrading my 2014 Mac Pro to OS X 10.10 (Yosemite).

It’s not that I don’t have anything more to say about OS X or other topics. It’s just that I find it less time-consuming and more immediate to post things on Twitter, in spite of the limitations of the medium.

I also have been feeling rather discouraged about the whole computing thing. It’s something that’s been building up for years. From my atrociously noisy Power Mac G4 MDD to my Faraday-cage PowerBook G4 that couldn’t get a wireless signal to the mooing MacBook disaster to my kernel-panicking Power Mac G5 to the seemingly never-ending list of long-standing bugs in Apple’s software and its general untrustworthiness as a purveyor of quality, reliable productivity software (hello, Pages 5), I can’t help but feel that the number of on-going problems with my computing setup outweighs whatever enthusiasm I might still have in me about technology in general and computing with Apple products in particular.

And so the reserves of energy and time that I am willing to devote to writing about these things have become somewhat depleted.

That being said, unlike some people, I cannot stay behind the times for very long. There’s just no way that I can continue to work and play with an operating system that is several years old and no longer updated.

After the trauma of my experience with Yosemite, you won’t be surprised to hear that I decided to take my own sweet time with the upgrade to El Capitan. With Yosemite, I had waited until the official release of OS X 10.10.1 before upgrading from Mountain Lion. And it’s only when OS X 10.10.3 came out, several months later, than my major responsiveness issues with the Mac Pro were finally resolved. So I decided to wait until at least OS X 10.11.3 before upgrading to El Capitan.

Don’t get me wrong. It’s not that I was happy with my Yosemite-based system. While the major responsiveness issues were solved by the OS X 10.10.3 update, there were still many less obvious, but still extremely irritating responsiveness issues that were never fixed in Yosemite, even with the release of the OS X 10.10.5 update (the latest available). And there were, of course, a number of other bugs that were quite annoying to live with, not to mention the very questionable choice of Helvetica Neue as the system font.

Apple touted El Capitan as primarily a “bug fix” release, even though, of course, its marketing material focused on yet more new features — most of which held little interest for me (except for the promise of “across-the-board acceleration” and a Mac that would “feel more fluid and responsive”).

However, after the initial release of El Capitan, I saw a number of reports online on yet more new bugs introduced by this latest OS. Of course, it’s always difficult to get a proper sense of how bad things really are when you read about other people’s experiences online. But several specific things that people reported about El Capitan made me quite worried, and conforted me in my choice to wait things out.

Finally, a week ago, I completed a big project that had kept me busy for a whole month, and I decided that my “reward” for completing it would be to take some time to install El Capitan. At that stage, OS X 10.11.3 was officially out and AppleSeed had already released several iterations of the 10.11.4 update, so I thought it was a reasonable time to give it a try.

Responsiveness and Fluidity

I took all the usual precautions, of course, and made sure that I could easily fall back on my Yosemite-based setup if things turned out to be disastrous again, as they were with OS X 10.10.1 for me back in December 2014. I also made sure that all my third-party software was perfectly up-to-date.

And then I took the plunge. The upgrading process itself was rather worrisome, because there were long periods of time where nothing (absolutely nothing) was happening on the screen and I was really worried about the upgrade process having become stuck. (The progress bars and status messages were, on the whole, pretty much useless on my machine.) Thankfully, I managed to be patient enough to ignore those worrying signs and wait it out, and finally, after something like 90 minutes, the upgrade sorted itself out and I was back up and running.

My initial impression was fairly positive. There were only a few relatively minor glitches. There were no new obvious “big bugs” that might have been deal-breakers or at the very least very painful problems to have to live with for a while. And the whole system did indeed feel significantly more fluid and responsive on my Mac Pro than Yosemite ever did.

Now, a week later, I can confirm that there are indeed significant improvements in that department. I am afraid that, in Yosemite, Apple really got too far ahead of itself in the revamp of OS X’s UI and built something that was far from optimized for a setup such as mine (i.e. a 2014 Mac Pro with two monitors, a conventional 30” Apple Cinema display and a more recent 4K Sharp display), especially when it came to graphics acceleration and overall visual fluidity. There were far too many unpleasant “hiccups” in the Yosemite UI to which I — as a user who tends to work very fast (fast typing, fast use of the mouse and keyboard shortcuts) and uses several tools to automate a large number of tasks — was far too sensitive. Those hiccups were impossible to get used to for me, and were one of the main reasons why, in the end, I was quite anxious to upgrade to El Capitan and see if it wasn’t “all in my head”, and if Apple had indeed taken the task of making the OS more responsive for users like me seriously enough.

El Capitan is decidedly more fluid than Yosemite. Most of the hiccups that would be so annoying to me in Yosemite are gone. There is still the occasional noticeable delay in this or that, but not often enough to be a significant annoyance for me. I no longer notice times when the OS takes a fraction of a second to draw a menu after I’ve clicked on its heading, for example. (The weird way that OS X draws the blue highlighting for the “Help” menu heading, which I noticed first in Yosemite, is still there in El Capitan, however, but I don’t use that menu — which is rarely all that helpful — often enough to really be bothered by it.) And I no longer notice hiccups when dialog sheets (like the “Save As…” dialog) drop out of window title bars.

In fact, El Capitan’s responsiveness improvements are such that they have made even using this horrible kludge of a piece of software called Microsoft Word 2016 (something that I cannot escape in my line of work) not as painful as it was in Yosemite. Word 2016 is still a horrible application and it still has all kinds of responsiveness issues of its own, but at least they are no longer compounded by OS X’s own responsiveness issues, which means that they are somewhat more tolerable (but still unacceptable, of course).

(Another obvious change in Word 2016 in El Capitan is that now, when I open a Word document from the Finder, Word first displays a big black rectangle, and then fills it with the document window. It’s rather unsightly, although, of course, quite harmless, and only lasts for a fraction of a second. Microsoft has never had any shame about such subpar finish in its software, so I don’t expect that this purely cosmestic issue will be fixed any time soon.)

Even more important, the problem with keystrokes occasionally disappearing in the ether (instead of being buffered, and eventually properly processed) because of responsiveness issues with OS X seems to be gone, or at least greatly reduced. (It’s hard to reproduce such an intermittent problem.)

I was also pleasantly surprised by how few Keyboard Maestro macros I had to update after upgrading to El Capitan. My experience with the upgrade to Yosemite had been that several macros needed to be adjusted because of responsiveness issues and other changes and glitches. In El Capitan, I only had to make one significant change, to my macro for sending messages in Mail (which automatically adjusts font size for rich text messages), because Apple changed something in in the GUI scripting architecture (via System Events) for that application.

Mail

In fact, OS X Mail was one of my main areas of concern for the upgrade to El Capitan, because I had read reports about new bugs in the application, and I rely on it too much to be able to live with too many bugs. Fortunately, while many of Mail’s existing, long-standing bugs still aren’t fixed in El Capitan, I have yet to encounter any significant new bugs that really affect me in my use of it. The only notable ones so far are the following.

Mail loses the focus on the file list when I use the “Attach Files” dialog box to add attachments to a message that I am composing and when I take the extra step of Quick-Looking the files to check them before attaching them (a reasonable enough habit, I believe!). But I’ve submitted a bug report about it, and Apple has already responded by closing it as a duplicate, so the early signs are encouraging.

Also, there is a significant problem with the toolbar in the window for composing messages. Unlike toolbars elsewhere in Mail, this toolbar no longer displays the text labels under the button icons, and the option to force the toolbar to display these text labels is gone from the “Customize Toolbar…” dialog sheet:

mail-send-toolbar1

mail-send-toolbar2

mail-send-toolbar3

I hope that this is a bug that was introduced accidentally, and that it’s going to be fixed soon, because it’s kind of annoying, even for someone like me who pretty much knows what each button icon means. I still rely of the text labels as well for faster targeting.

One other noticeable change (for me) is that the information provided in Mail’s “Activity” window is now much more limited, to the point of being almost useless. I’ve always relied on that window to get a better sense of what was going on behind the scenes in Mail, especially when my bandwidth was much more limited than it is today. When things work fine, I don’t really need it, of course. But I don’t know what’s going to happen the next time I start having some serious problem with a mail server. (Also, Mail no longer has an optional pane for a more summary display of its background activities at the bottom of the mailbox list. Instead, it just displays a small status line from time to time at the bottom, on top of the list, whether you want it or not.)

I still find it rather irritating to have to deal with Mail’s very clumsy and buggy mechanism for removing attachments from messages before archiving them. The problems introduced in Yosemite (especially when removing attachments from emails in discussion threads, a.k.a. “conversations”) are still there in El Capitan, and the even older problems haven’t been addressed either. There has been absolutely no progress on that front, even though removing attachments is an important tool in order to try and keep the total size of one’s email archive reasonably low. (Mine currently weighs over 2 GB. I hate to think what it would weigh if I had left all these attachments in the messages when archiving them.)

And Mail’s text rendering engine still gleefully treats non-breaking spaces as regular, breakable spaces, which is quite problematic in French typography (although there’s probably no one at Cupertino who really cares about this).

On a positive note, however, Mail no longer freezes for 20 seconds every time I try to access the “Accounts” pane in its “Preferences” dialog, which I am quite relieved about. Also, the long-standing issue that I had with Mail failing to flag my sent messages as having attachments (when they did contain attachments) and therefore preventing me from removing said attachments (because it didn’t see them) appears to be gone.

And Apple has even fixed the long-standing bug with selection highlighting in Mail when it was hidden by the “Hide Others” menu command while in the background. It still took them five bloody years to fix it, but at least it’s finally gone (as is the similar selection-highlighting problem in various other applications that I use, especially stand-alone, site-specific Safari-based web browsers created using Fluid).

Other OS X Applications

In other OS X applications, some long-standing problems remain, such as Preview’s inability to keep up with very fast window resizing (especially problematic if you use Keyboard Maestro macros to resize your windows).

The Finder still suffers from that annoying glitch where OS X fails to invert the text of the folder name when dragging a file onto a folder in a background window:

ScreenFlowSnapz002

(And I’ve also already encountered the glitch where the Finder fails to highlight the target of a drag-and-drop altogether, so that’s not completely fixed either.)

Apple has changed something in the system that causes the font smoothing in Numbers 3.6 to be somewhat better for some fonts (Helvetican Neue, for one), but it still does not use subpixel antialiasing like it does in another applications, at least on my computer:

NumbersSnapz001

Spotlight still fails to automatically index new “.docx” documents that I add to my system (whether by creating them from scratch or by saving them as attachments from email messages), which is rather annoying. I was hoping that this was going to be fixed in El Capitan, because the last response I got from Bug Reporter about this problem last year (when I was still running Yosemite) was a request to confirm whether the problem was fixed in… the latest build of El Capitan at the time, which of course was very unhelpful, because there was no way I was going to upgrade to El Capitan back then (which was still then in beta form), just in order to check if this particular bug was fixed.

I gave up on Spotlight as a serious search tool long ago, and tend to rely on the (rather expensive, but effective and reliable) FoxTrot Professional Search application by CTM Development for my searches, but the chronic failure to automatically index new “.docx” documents is still an annoyance.

I actually ended up following the advice in this thread at Apple Discussions (I am obviously not the only one with this problem) to create a Terminal command for forcing Spotlight to index new “.docx” documents, and using CronniX to add this command to my system as a task to be automatically executed every day.

But really, should I, as a Mac user, really have to go to such lengths to work around your problems, Apple?

Another thing that I was looking forward to in El Capitan is the ability to shake the mouse to magnify the cursor, when I lose track of it on my large screens… It works, but it doesn’t work as well as I had hoped. I occasionally get cursor magnification during regular mouse movements, when I don’t want or need it, and when I do want the magnification, I find that the amount of shaking required is a bit excessive. I hope the feature will be fine-tuned in the future. (It might work better with a wireless mouse, but I still use the wired Apple Mouse.)

Sadly, the problem with OS X failing to change the mouse cursor reliably based on the context, which was introduced in Yosemite, is also still there in El Capitan. This problem is brilliantly illustrated by Eli Schiff in a YouTube video here. (The video was made with Yosemite, but as far as I can tell the problem still exists in El Capitan.)

The new San Francisco system font is indeed much nicer than Helvetica Neue, and we should never have had to live with Helvetica Neue for a year (and I really feel for those who are obliged, for whatever reason, to stick with Yosemite). Like other commentators, however, I do find that the lack of distinction between the opening and the closing single quotes and double quotes is quite problematic.

The problems with OS X’s architecture for “resuming” applications (i.e. reopening the windows that were left open when the application was last quit) are still there in El Capitan. TextEdit still seems unable to resume properly after a system restart, and I’ve already had an incident where I accidentally interrupted a system restart triggered by a software update and, after manually triggering the restart myself, I ended up with a complete failure of the resume feature in the Finder, which meant that I had to reopen all my Finder windows and tabs manually.

Conclusion

That’s about all that I can say for now, after one week. Overall, I am quite pleased with having upgraded to El Capitan. The singlemost important improvement for me is the responsiveness and fluidity of the UI. It’s not perfect, but it is much, much better than it was with Yosemite on the same hardware. The upgrade is worth it just for that.

I am also quite pleased to find that Apple has indeed fixed some long-standing bugs that had been a daily annoyance for me for years. I can actually now eliminate some of my Keyboard Maestro macros, because they are no longer needed to work around those bugs.

Unfortunately, there are still many issues that remain unaddressed, in Mail and in other OS X applications, which make the upgrade less impressive as a “bug-fixing” release than I had hoped it would be. Given that Apple’s recent history indicates that no significant additional bug fixes will come in subsequent incremental updates for El Capitan (other than for bugs introduced in El Capitan itself), and that the next version of OS X might not have as much a focus on bug fixing as this one, I fear that I might have to continue to live with those remaining annoyances for many more years.

El Capitan does not significantly alter my current feelings about computing in general. Sure, it’s not as painful to use as Yosemite was, but it’s still far from being as polished as I’d like it to be, as some of the problems highlighted above demonstrate.

Will the next version of OS X be another step forward or a new step back? Time will tell… But if you haven’t upgraded to El Capitan yet and needed to know more about what it brings, I hope that the above addresses at least some of your questions and concerns.


OS X 10.10.3: Fixes major responsiveness issues on 2014 Mac Pro

Posted by Pierre Igot in: Macintosh
April 15th, 2015 • 6:03 pm

This 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 Mavericks and worked pretty well until I upgraded to Yosemite.

I waited until OS X 10.10.1 came out before upgrading, but this was still not cautious enough. I soon realized that, on my Mac Pro, Yosemite suffered from significant responsiveness issues that were not tied to any specific piece of software or to a particularly high level of CPU activity.

When I say “significant”, I really mean it. These were not just slight delays that one can accept to live with in a 1.0 or 1.0.1 version of a new software product until the developers get around to further optimizing the software. These were massive, outrageous delays in seemingly simple tasks, such as switching apps, clicking on menu headings to pull them down, resizing windows, etc.

As an experienced troubleshooter myself, I went through all kinds of steps to try and isolate the problem and hopefully find a solution. Nothing worked. There was not a single application that I could identify as the culprit. It soon became quite clear to me, with my extensive experience as a troubleshooter, that this was a problem with the OS itself.

In desperation, I even went so far as to do a brand new “clean install” of my system and applications — something that I hadn’t done in years. When you use a fairly advanced setup such as mine, with a number of third-party applications and lots of customizations (none of which would qualify as “hacks”, although Apple probably does not do much in-house testing to ensure that utilities such as Default Folder X, Typinator and Keyboard Maestro always work well with their latest system software), doing a clean install is a very tedious, time-consuming process, because you not only have to migrate all your files back and reinstall all your applications, but also restore all the customizations one by one, without relying on existing application support files that might have somehow become “corrupted”.

But I did it, and even before I had completed the process of restoring all my customizations, I knew that the clean install had not solved the issue.

The problem with responsiveness issues is obviously that they are somewhat subjective. I am a fast typist and, generally speaking, a fast GUI user. I even use Keyboard Maestro to automate a number of repetitive interactions with the GUI using macros; those macros effectively mimic the behaviour of an extremely fast GUI user. So I am particularly sensitive to responsiveness issues. And let me tell you, on my machine at least, the situation was a nightmare.

I had all kinds of Keyboard Maestro macros that no longer worked properly because the system was not responsive enough, so I had to artificially add all kinds of built-in delays to the macros to try and make them work with the OS. (And even that only went so far, because the system’s own delays were not consistent and predictable.)

But even in my own “manual” interactions with the Yosemite GUI, I was hampered by all kinds of undesirable delays that would cause me to miss targets, accidentally trigger things I didn’t mean to trigger, etc. It was maddening!

Given that my Mac Pro was a recent purchase and that this was clearly an unacceptable level of responsiveness on a supposedly fast machine, I felt that I had no choice but to go through Apple Care. I won’t get into all the details, because telling them in full would be far too long, but suffice to say that I “burned through” four different “senior representatives”, who all agreed that what I was experiencing was unacceptable, but were at a loss to explain it, let alone reproduce it themselves or get their engineering counterparts to acknowledge the seriousness of the situation and do something about it.

Things were so bad that there was talk, at some point, of downgrading to OS X 10.9, or even of trying to get my Mac Pro’s video cards replaced, in case that might somehow miraculously fix the problem — as if it wasn’t obvious enough that this was a software problem and not a hardware problem.

I spent a lot of time executing troubleshooting tasks for the senior representatives, or for the engineering people that they were talking to about my issues, all the while knowing very well that none of them would do anything to fix the problem.

What was particularly maddening, of course, was that responsiveness issues are hard to capture, and also tend to be intermittent in nature, which means that you often cannot reproduce them on demand. However, I did end up purchasing a piece of software (ScreenFlow) that enabled me to create video captures of some of the most egregious problems, and I was also able to narrow down, to some extent, the circumstances under which the responsiveness problems would occur.

Unfortunately, I also wasted a lot of time on what can only be described, in retrospect, as wild goose chases, because I was seeing various behaviours that seemed to be connected but ultimately proved to be unrelated (or loosely related at best) to my responsiveness issues. For instance, I couldn’t help but notice that Yosemite was eating up the 32 GB of physical RAM on my Mac Pro like candy, and that responsiveness issues seemed to be getting worse the closer I got to 32 GB of memory used. The last senior representative that I talked to seemed to be unable to find out whether this kind of RAM usage was normal in Yosemite or not, and couldn’t explain, for instance, how a single web page left open in Safari could end up using 1.5+ GB of memory all by itself, on top of the memory used by the Safari process itself.

While Apple Care’s representatives proved to be unable to help me in any significant way, I was fortunate enough to get a variety of suggestions and tips from readers of this blog and my Twitter feed. This is how, for example, I found out that having turned the “Reduce transparency” option on in the Accessibility settings in System Preferences was actually causing a significant menu-flashing bug on top of my general responsiveness issues, and I ended up using the “Increase contrast” option in the same Accessibility settings for a while, because it helped reduce the severity of this bug and also, somehow, seemed to slightly alleviate the general responsiveness issues in Yosemite on my machine.

I, of course, had mentioned to the Apple Care representatives that I was also a member of AppleSeed and, as such, had access to early builds of the next system upgrade, OS X 10.10.3. (OS X 10.10.2 had come out early on with no improvements.) I asked whether it was a good idea, in my circumstances, to give those early builds of 10.10.3 a try. The representative that I was in touch with at the time was obviously at a loss himself and figured that I didn’t have much to lose. So I did proceed with the installation.

The very first 10.10.3 build available through AppleSeed included the new Photos application, but did nothing to alleviate my problems, so I was not particularly hopeful that things would get better in subsequent builds (worried as I was that the focus would be mostly on this new Photos application and not on fixing bugs).

But then two things happened. I got a tip from a reader about this post on Reddit, which suggested a link between responsiveness issues in Yosemite and a specific kernel extension (AppleGraphicsPowerManagement.kext). I was intrigued, because I had always suspected (with my limited knowledge of the engineering underpinnings of OS X) that, in the effort to minimize battery consumption for laptop computers, Apple had gone too far in implementing mechanisms that put all kinds of things to sleep automatically when idle. Certainly, several of my responsiveness issues looked like problems where, when I was clicking on something, the computer system appeared to be somehow “waking up”, and only responded to my clicks after a few seconds. And of course, my responsiveness issues had everything to do with the GUI, i.e. with “graphics”, and I had been suspecting problems with graphics drivers all along.

And then within a few hours of that discovery, AppleSeed released a new build of the OS X 10.10.3 update, which I installed, and which included a number of updated versions of kernel extensions, including this particular one (and several other graphics drivers)!

I soon realized that this update was a major step forward, that it clearly addressed several of the issues that I had been experiencing. For instance, the menu-flashing bug was completely gone. There would still be the occasional slight delay between a click on a menu heading or button and the appearance of the actual menu, but there was no longer a problem with the menu flashing and disappearing before I had a chance to make a selection.

Most important, however, was the fact that the general problem with the massive delays that I had been experiencing on my Mac Pro was gone.

I am not sure I can convey how relieved I felt at this point. I immediately communicated with the Apple Care senior representative that I was in touch with. He, of course, had no inkling that this particular build might feature any bug fix that would address the problem that we had been discussing for over two months. He was just as pleasantly surprised to hear about this.

While I was expressing my huge relief to him, I also made it quite clear that I didn’t feel that this outcome made everything alright and that everything that had come before then was forgotten (let alone forgiven). For one thing, I had no guarantee (nor did he) that whatever this particular build fixed would not be broken again in subsequent builds. Since no one on the engineering side had communicated with him about the fact that this build might contain a fix, we had no idea whether the fix was even intentional — and not simply an accidental by-product of some other improvement or optimization.

In fact, I was so worried about this that I refrained from installing any subsequent builds of the 10.10.3 update until the official update came out last week. I wanted to make sure that I had a system that worked, and given that I was otherwise very busy, the easiest solution was to do nothing. Then when the update finally came out, I made sure I had an up-to-date backup of my existing system that was updated right before I installed the update, and I made sure I immediately tested the final version of the update to confirm that the responsiveness problems had not come back. (They had not.)

I also made it quite clear to the senior representative that I felt that there had been massive communication issues between the engineering side and the customer service side at Apple, and that this had caused me and him to waste lots of time on wild goose chases and other useless (in retrospect) troubleshooting steps. While he himself was at least getting paid for dealing with me, I, on the other hand, had no way to get any compensation for the countless hours I had spent on troubleshooting this problem. If at least Apple’s engineers had said, early on, “Yes, we know that there is a major responsiveness issue for some users, and we’re working on a fix, which should be available around such and such a date”, then we would not have wasted so much time!

There is a part of me that still hasn’t forgiven Apple for this, and maybe never will. The whole experience has been very traumatizing, and I am really angry at Apple for having caused me to waste so much of my time on trying to fix a problem that I could do nothing about. As I said to the senior representative, “the impression of callousness on the part of Apple’s engineers will take a very long time to dissipate”. I realize that this particular problem probably only affected a small minority of users, but when someone goes through four different senior representatives, provides reliable scenarios for reproducing specific issues, provides graphic evidence in the form of screen captures (the engineers even asked me to record a video of my monitor with my iPhone at some point!), and clearly demonstrates that he is no fool and knows what he is talking about, the issue has to be treated more seriously and professionally, with a more acceptable level of… responsiveness in the communication itself.

I cannot help but feel, at times, that Apple’s engineers think that they are above all this and incapable of making such egregious mistakes that cause significant hardship for some of their users. While I agree that customer complaints might not always be entirely legitimate and that some users are fussy and moan about things that, in the big picture, are really rather small potatoes, this was not one of those cases. The issues I had were very real, and the very fact that they were suddenly fixed by a single system update proves that they were.

Because of the lack of communication, I still don’t know if Apple’s engineers even realize that they have fixed those significant responsiveness issues for me (and hopefully others). Part of me is still afraid that I might encounter a regression in a future system update. But at least now I had an official version of Yosemite that I can fall back on if things go awry again.

In closing, I should also stress that this is not the end of my complaints about responsiveness in Yosemite. There are still multiple aspects of the GUI in Yosemite that don’t feel right to me. The responsiveness issues are no longer egregious to the point that I find them unbearable, but there are still problems, including several bugs that I identified in the process of trying to further circumscribe the issues that were specific to my Mac Pro and mistakenly took as manifestations of these issues, when in fact they were just made more visible and noticeable by the massive delays that my responsiveness issues were causing.

I still often notice, for example, a slight delay between the time I click on a menu heading in the toolbar and the time the blue highlighting behind the heading comes on and the menu below gets drawn. It’s a small fraction of a second, but it’s noticeable. It doesn’t affect my ability to use the menu, but it makes the whole process feel slower.

The particular problem that I identified in this blog post about the blue highlighting for the “Help” menu is still there. It’s cosmetic, but it looks sloppy.

The bug in OS X’s Preview that causes it to fail to keep up with fast window resizing (especially when using a Keyboard Maestro macro) is still there.

And there are, more generally, multiple situations where you can almost witness the process of Yosemite “building” the user interface in real time. For example, yesterday I posted on Twitter a link to this video recording that I created and that shows what happens when I play back, in slow motion, a video recording of System Preferences drawing the “General” preference pane in real time in Yosemite. This video clip, which is effectively the recording of the playback of a recording, shows that there is a delay of 0.07 second between the time the contents of the “General” preference pane appear and the time some of the blue highlighting that should be part of the UI appears (the blue highlights on the radio buttons, the blue highlights on the arrows for the pop-up menus, etc.).

Why is there such a delay? It is not caused by some background activity that would happen to be slowing my system down at the time. The 0.07-second delay happens each and every time I access the “General” preference pane. It’s a small delay, but it’s noticeable. And it certainly contributes to the feeling that Yosemite is slow, even if it’s not really that slow.

I don’t know what Apple did to the GUI in Yosemite. They clearly rebuilt a lot of things (the font change to Helvetica playing an important part in this process), and in the process they created a lack of smoothness, fluidity, and zippiness that is really quite disturbing. It makes you feel like you using a system that is somehow more “fragile”, less reliable, less solid and could fall apart at any point — something that Apple’s engineers have decided is “good enough” for most people, but that more demanding, more attentive users will find rather disappointing and unworthy of Apple’s legendary attention to detail (which is becoming more and more of a legend and less and less of a reality with every passing year, I am afraid).

I cannot finish this post without thanking all the Betalogue readers and Twitter followers who have written to me to share their own stories and offer suggestions, tips, or simply commiseration. Unlike Apple’s customer service, they were actually able, collectively, to make a difference for me, and I can only hope that, with this blog post, I in turn might able to make a difference for other users.


OS X Activity Monitor: Yet more evidence of Apple’s sloppy work in Yosemite

Posted by Pierre Igot in: Macintosh, Mail
March 13th, 2015 • 5:00 pm

Here’s another example of Apple’s sloppy work in OS X 10.10 (Yosemite) that is very easy to reproduce (at least on my Mac Pro):

  1. Open the Activity Monitor application (in the Application/Utilities folder).
  2. Option-click on your desktop to hide the foreground application, i.e. Activity Monitor, and switch back to the Finder.
  3. Click on the Activity Monitor icon in the Dock or press command-Tab to switch back to Activity Monitor.

Notice anything? The toolbar now looks like this:

yosemite-activity-monitor1

Normally, when Activity Monitor is in the foreground, the toolbar should look like this:

yosemite-activity-monitor2

In other words, somehow Yosemite “forgets” to switch the background chrome of the window toolbar back to its foreground version. Yet the window is indeed in the foreground, as indicated by the three coloured buttons on the left, which are coloured (and not greyed-out), i.e. in the state they are supposed to be in when the window is in the foreground.

And even the other toolbar buttons that look like they are in the background and disabled are actually active and you can click on them. (This actually forces them to switch back to their normal foreground state visually, one by one.)

So the issue is purely cosmetic. But it’s still very sloppy on Apple’s part.

I haven’t been able to reproduce this problem with any other application. I also cannot reproduce the problem when step #2 in the process above involves choosing “Hide Activity Monitor” in the “Activity Monitor” application menu. But I can also reproduce it when I switch to another application and use “Hide Others” to hide all other applications, including Activity Monitor.

Fixing the problem involves switching to another application and then back to Activity Monitor. This forces a “refresh” of the window display and then Activity Monitor uses the appropriate chrome for the foreground window.

This is not the first bug I have encountered in OS X with the system’s commands for hiding applications. Long-time Betalogue readers might remember that I reported, back in 2012, on a selection-highlighting bug that was first introduced in Lion and has been with us ever since. Because of this bug, after I use “Hide Others” to hide all applications other than the foreground application, if the applications thus hidden include Mail, when I bring Mail back to the foreground, it continues to use the background (grey) colour to highlight messages in the message list, and it also fails to make the I-beam cursor visible in messages that are in the process of being edited.

The same bug also affects, for some reason, stand-alone Safari-based web browsers created with the Fluid application. I have several of those and they all suffer from the same problem as Mail. If they are hidden by “Hide Others” and then brought back to the foreground, the selection highlighting is all wrong.

Here again, fixing the problem involves switching to another application and then back to Mail or the affected stand-alone browser app. In fact, it’s such an annoyance that I have created Keyboard Maestro macros to execute this fix each time I switch to those applications, because I use “Hide Others” all the time and so my stand-alone browser apps often end up in this undesirable state.

This selection-highlighting bug has now been with us for three years. And now, thanks to Apple’s sloppy work in Yosemite, we can add a new one to the list, which only affects Activity Monitor, but is definitely easy to reproduce (at least on my system).

Sigh.


OS X 10.10 (Yosemite): Preview fails to keep up with fast window resizing (continued)

Posted by Pierre Igot in: Macintosh
March 9th, 2015 • 1:31 pm

Since my original post about a bug with window resizing in Preview in Yosemite, I have received feedback indicating that not everyone is able to reproduce this bug on their system.

This leads me to suspect that the problem might be limited to specific hardware configurations, like the other responsiveness issues that I have be experiencing since upgrading to Yosemite, which seem to all involve issues of drawing/refreshing the contents of windows, menus, etc. on the screen.

In my original post, I indicated that, in order to reproduce the problem, you really had to use very quick mouse movements in Preview, which will cause it to fail to keep up with your window resizing and only partly resize its contents to fit the frame.

I also indicated that the issue was particularly noticeable when using Keyboard Maestro macros, because these macros effectively mimic very fast mouse movements — in fact faster than what the human hand can achieve.

This means that, while reproducing the problem with a human hand can be challenging, with a Keyboard Maestro macro I am able to reproduce the bug reliably 100% of the time.

So in the interest of further identifying the circumstances under which this Yosemite bug occurs, here is a scenario involving Keyboard Maestro that makes it possible to reproduce the bug without fail:

  1. If you don’t have it yet, download and install Keyboard Maestro on your system.
  2. Create the following macro (or download it here and import it) or a similar one:
  3. km-resize

  4. Open any PDF document in Preview and switch the view mode to “Single Page” (in the “View” menu).
  5. Make the Preview window containing the PDF fairly small.
  6. Execute the macro.

If you have the same bug I have on my system (a 2014 Mac Pro), then the window will resize properly, but Preview will entirely fail to scale the contents to fit the resized window, as it normally should.

The only way to force Preview to scale the contents of the window is to adjust the window size a second time. This will force it to “refresh” the contents and redraw the page at the size it should normally be in a window of that size.

If you can reproduce this bug on your system, I would be very interested to know about it. Please use the link in the sidebar to contact me and send me your hardware configuration.

Thanks!


OS X 10.10 (Yosemite): Preview fails to keep up with fast window resizing

Posted by Pierre Igot in: Macintosh
March 6th, 2015 • 5:56 pm

Here’s a typical example of the many things that are wrong in Yosemite in terms of performance and responsiveness. When you first upgrade to Yosemite, you might notice all kinds of different responsiveness issues and it can be all quite confusing, giving you a general impression of unresponsiveness even though you cannot quite clearly pinpoint what is wrong.

Over time, however, it gradually becomes easier to identify specific behaviours in specific applications that help explain this general impression. Here is one such specific behaviour.

It has to do with the Preview application and with what happens when you view a PDF in “Single Page” view mode and you resize the window to make it bigger.

In order to reproduce the problem you need to do the following:

  1. Open a PDF file (any PDF file will do) in Preview.
  2. In Preview, go to the “View” menu and select the “Single Page” option (as opposed to the default “Continuous Scroll”).
  3. Then grab the bottom-right corner of the window and resize it to make it quite small.
  4. Then grab the bottom-right corner of the window again and drag it to the right and down as fast as you can with your mouse.

The speed is important here. If you drag it at a “normal” speed, you won’t encounter any problems.

If you drag it fast enough, on the other hand, sooner or later this will happen:

(Click here to get the MP4 video on DropBox.)

Note the situation in the video around the 02:00 mark: Even though the window’s bottom-right corner is near the edge of the video frame, the bottom-right corner of the PDF page is nowhere near that edge. It’s because I’ve resized the window too fast for Preview, and it has failed to keep up with my mouse movement.

But I’ve kept my mouse button down. And around the 03:00 mark, I nudge the mouse pointer a little bit more, which forces Preview to finally refresh its display of the PDF page so that it properly fills the space available inside the window’s edge (allowing for a tiny bit of padding for esthetic reasons, of course).

How pathetic is this? My hardware is not to blame: I have a very powerful 2014 Mac Pro with tons of RAM, and there’s nothing running in the background that would excuse such a shortcoming. (In actual fact, the ScreenFlow application is running and recording all this in real time, of course, but this behaviour is perfectly reproducible even when ScreenFlow is not running.)

Now, you might be tempted to say: “Yeah, but who resizes at that speed with the mouse anyway? If you resize at a more ‘normal’ speed, there is no problem here.” And that might be what Apple’s engineers think. (In other words, things are “good enough” for most users here.)

Well, for one thing, this is a pretty sad attitude to have. There is no question that my Mac is powerful enough and that Preview should not be struggling with this. Any self-respecting engineer who strives for excellence in his or her work should be dissatisfied with this and insist that the problem be fixed.

And then there’s the fact that it effectively penalizes users for being too fast! In what world is that considered OK? We live in an age of superfast hardware that should have no trouble keeping up with human interactions, especially when everything is local and no networking is involved. Yes, I am a fast user. So what? Does it really make me a bad user?

Finally, there’s one more thing: This shortcoming has a significant impact on people who, like me, might use Keyboard Maestro to automate various tasks, including the moving and resizing of windows in OS X. I have two large monitors and I have several macros that enable me to automatically move and resize my windows in any OS X application, including Preview, so that I can easily organize my document windows side by side on either screen.

I often have four different documents open in four different windows side by side and my large screens enable me to me to view these documents at a fairly low zoom level while maintaining legibility. But the two screens do not have the same size/resolution, and so when I switch a document window from one screen to the other I need to resize it. If that resizing involves a PDF document open in a window in Preview, then guess what happens?

Well, for window manipulation, Keyboard Maestro’s macros effectively behave like a superfast user, mimicking mouse movements at the fastest possible speed. So of course they are going to be affected by this bug in Yosemite’s Preview application. Sure enough, every time I use a macro that includes a step like this one:

km-move-resize-window

and the window involved happens to be on my second screen, where the window size has to be smaller, the macro correctly moves it to the main screen and correctly resizes the window to fill the bigger screen, but Preview fails to keep up with it and so the PDF page in the window is not resized properly.

In fact, Keyboard Maestro is faster than I’ll ever be with my mouse, and it’s so fast that Preview fails to resize the PDF page itself altogether! The window is bigger, but the PDF page keeps the same size it had on the secondary screen.

The only solution that I have found to work around this problem is to add an extra step to the macro, just for Preview:

km-move-resize-window-nudge

This extra step effectively mimicks the little nudge illustrated around the 03:00 mark in the video above, which forces Preview to refresh its display of the PDF page so that it finally fills the space available inside the window.

But it’s not an ideal solution, because any extra step like this increases the risk that something might go wrong during the execution of the macro. If Yosemite experiences any kind of “hiccup” during the execution (which it tends to do), then the nudge might not work as expected and I will still have to resize the window manually in order to force Preview to refresh its display of the PDF page.

This is a new problem in Yosemite. Preview in Mavericks never had such a problem, and I had been using my Keyboard Maestro macros with it for a long time without a hitch.

When people talk about Apple’s sloppy work in Yosemite, I believe that this is the kind of thing that they are thinking of. It took me a while to narrow it down because of all the other responsiveness problems I was having with Yosemite, but this, as far as I can tell, is an easily reproducible problem for anyone running Yosemite, even people who don’t have the egregious responsiveness problems that I have been experiencing.

When will Apple get around to fixing it (if ever)? Unfortunately, because the application works “well enough” for the majority of users, I am not too optimistic, which is why I’ll have to keep this extra “nudge” step in my macros and in my own dragging movements for quite a while, I fear.

rdar://20069961


Word 2011 for OS X: Easily confused

Posted by Pierre Igot in: Microsoft
March 5th, 2015 • 3:44 pm

If you’ve ever felt like confusing the heck out of Word 2011 for OS X just for fun (and who wouldn’t, really?), try this:

  1. In the Finder, create a folder called “Confused Word” on your desktop.
  2. In Word 2011, create a new document and save it as “Test1.docx” in the “Confused Word” folder. Leave the document open in a document window in Word.
  3. In the Finder, select the “Test1.docx” file in the “Confused Word” folder, make its name editable, and change it to “Test2.docx”.
  4. Switch back to Word 2011 and confirm that the document window you left open now has the document title “Test2.docx” instead of “Test1.docx”.
  5. Switch back to the Finder, select the newly renamed “Test2.docx” file and duplicate it to create a second file in the same folder called “Test2 copy.docx”.
  6. Make the file name “Test2 copy.docx” editable and change it to “Test1.docx”.
  7. Double-click on “Test1.docx” to open it in Word 2011.

The first strange thing that happens is that the “Test1.docx” document opens as “Read-Only”. Why? I have absolutely no idea.

But now hit command-S in Word 2011 to save the “Test1.docx” document that is labelled “Read-Only”.

Since it’s (allegedly) read-only, you’d think that Word 2011 would complain about your attempt to save it and ask you to save it under a new name or something, right?

Think again. Not only does Word 2011 not complain, but it actually changes the document title in the title bar to “Test2.docx (Read-Only)”!

As they say on the Interwebs, WTF?

It gets even funkier if, before hitting that command-S shortcut, you actually make some changes to the contents of the “Test1.docx” document. In that case, when you hit command-S, Word changes the document title in the title bar to “Test2.docx”, without the “Ready-Only” part. And guess what happens to the “Test2.docx” document that you’d left open in the other document window in Word 2011?

It gets renamed to something like “Word Work File D_xxxxxx.tmp”, where “xxxxxx” is a sequence of numbers. Admittedly, this is a very temporary situation, because as soon as you switch to another app and then back to Word 2011, the document title of that other document window changes back to “Test2.docx” as well.

So now you have two document windows with the same document title/file name and two different states for the content (since you typed something else in that other document window before hitting command-S, remember?).

And now guess what happens when you close those two document windows and return to the Finder?

Well, there are no longer two files inside that “Confused Word” folder on your desktop. There’s only one file left, called “Test1.docx”, and its contents do not include the changes you made to the document before hitting command-S.

Nice to know you’ve got our backs, Microsoft.


Numbers 3.5 (iWork): Hijacks cursor keys when editing cells

Posted by Pierre Igot in: Macintosh, Pages
February 27th, 2015 • 10:41 am

On February 25, 2015, I used Bug Reporter to submit the following bug report (#19951698) to Apple:

Summary:
When I select a cell and start typing, the cursor blinks inside the cell. Yet if I use the Left or Right cursor key, Numbers jumps to the previous/next cell, instead of navigating inside the current table cell.

Steps to Reproduce:
1. Open any Numbers document containing a table.
2. Select a table cell by clicking ONCE on it.
3. Start typing.
4. Press the Left or Right cursor key.

Expected Results:
I expect the Left or Right cursor key to move INSIDE the current table cell by one character to the left or to the right.

Actual Results:
The Left or Right cursor key JUMPS to the previous/next table cell.

Version:
Numbers 3.5.2.
OS X 10.10.2.

Notes:
To add insult to injury, the behaviour is not consistent across iWork apps. In tables in Pages, I get the expected behaviour.

I think this report is quite self-explanatory. For completeness’s sake, I probably should have added that when, instead of simply selecting a cell in Numbers before you start typing, you double-click on the cell to make its contents editable right away, then, for whatever reason, the cursor keys work as expected.

I can see absolutely no visual difference between a selected cell that becomes editable when you start typing and a cell that becomes editable when you double-click on it. And yet, in the first instance, the cursor keys do not work as expected — they jump from cell to cell, even though the I-beam cursor is blinking in the cell — whereas, in the second instance, they work as expected — they jump from character to character inside the cell whose contents you are currently editing.

I also should have pointed out that the impact of this hijacking of the cursor keys is that it also affects one’s ability to use the keyboard to navigate word-by-word inside cells, because the shortcuts for jumping from word to word inside a cell are the same standard shortcuts as elsewhere in OS X, i.e. option-Left and option-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use option-Left and option-Right, instead of jumping from word to word, the application actually gives to those shortcuts the meaning that they have when you are not inside a cell, i.e. they insert a new column to the left or to the right of the current column. (I have already written here about the idiocy of that other hijacking of commonly used keyboard shortcuts in iWork.)

And of course, the additional impact of this hijacking of the cursor keys is that it also affects one’s ability to select text inside cells, because the shortcuts for extending the selection to the left or to the right are based on the cursor keys and are shift-Left and shift-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use shift-Left and shift-Right, instead of extending the selection to the left or to the right inside the cell, the application gleefully selects you out of the cell and starts extending the selection of cells to the left or to the right.

(I should also mention the shift-option-Left and shift-option-Right shortcuts, which are also affected. In that case, Numbers ignores the Shift modifier and assumes that you meant to hit option-Left and option-Right, and so it inserts a new column to the left or to the right of the current column.)

Finally, it should be stressed that, when you enter a cell by double-clicking on it, all these other cursor-key-based shortcuts also work as expected, as do the cursor keys themselves. So at least the inconsistency is consistent (although I doubt very much that this is deliberate).

To Apple’s credit, I got an answer to my bug report within 48 hours:

Engineering has determined that this issue behaves as intended based on the following information:

Yes, this is behaving as designed. In tables in Pages we are expecting a user to type more text in a cell and so we favor text navigation with the arrow keys. For Numbers, we are expecting cells to contain short bits of data, like a number in each cell, so for that pattern we use the arrow keys to navigate to the next cell. That way a user could type 1, right arrow, 2, right arrow, 3, and quickly enter values into 3 cells.

If you have questions regarding this resolution, please update your bug report with that information.

We are now closing this bug report.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

I am afraid this makes very little sense. If indeed the idea behind the hijacking of the cursor keys is to enable the user to “quickly enter values” in a series of cells, then why is the behaviour different when the user double-clicks on a cell to make it editable?

In addition, we already have long-standing shortcuts for quickly entering values in a series of cells: the Tab and shift-Tab keys.

Also, just because the bits of data might be short, it does not mean that the user is less likely to make errors in his or her text input that require small corrections, which are one of the primary uses of cursor keys!

As well, the very reason for having universal, system-wide standard shortcuts is so that people can develop “muscle memory” that enables them to use these shortcuts in all contexts without even thinking and expect them to work all the time. Any application that hijacks universal keyboard shortcuts to give them a different meaning goes against such expectations, and there is simply no way that you can reasonably expect someone who has developed such muscle memory to remember to do the non-instinctive thing when she or he is in a specific application and refrain from using the shortcuts.

Finally, if indeed the expectation is that in tables in Pages, the user will “type more text in a cell”, and therefore have even more reason to use keyboard shortcuts for text navigation and selection, why are the keyboard shortcuts for word-by-word navigation and for extending text selection also hijacked in that application? (Granted, the hijacking there is limited to what happens when you are not inside a table cell, but it’s still far too easy to think that you are currently editing a cell and accidentally use these shortcuts when you shouldn’t.)

All this is to say that I cannot help but feel that the response I got from Apple is a lie and that nobody has really thought this through. If they had really thought this through and paid real attention to the issue, the behaviour would be the same whether you enter a cell by selecting it and starting to type or by double-clicking on it.

And even if the whole thing is deliberate, I think it’s the wrong decision. The theoretical advantage to some users (who might never have heard of the use of the Tab key to “quickly enter values” in consecutive cells) is simply far too insubstantial compared to the on-going disruption caused by this hijacking of universal, standard system-wide shortcuts.


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?

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.


OS X 10.10 (Yosemite): Responsiveness problems not solved by clean install

Posted by Pierre Igot in: Macintosh
December 8th, 2014 • 10:29 am

I just don’t understand.

Last week I reported about noticeable responsiveness issues that I was experiencing with OS X 10.10.1 (Yosemite) on my 2014 Mac Pro:

  1. visibly slow drawing of the blue highlighting behind the “Help” menu heading in the menu bar;
  2. interruptions when scrolling down a Finder window with a long list of files (namely, the /System/Library/Extensions/ folder, which contains over 200 .kext files) with the Magic Mouse;
  3. recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process;
  4. and, last but not least, recurring lack of responsiveness of various UI controls, including menu headings and buttons for pop-up menus.

I also mentioned that I had talked to someone (named Justin) at AppleCare, who had promised to escalate the issue if I couldn’t solve it with the usual troubleshooting steps.

On November 28, I called AppleCare again and talked to a man who seemed much less interested in my problem than Justin had been a few days before. However, to his credit, he promptly put me in touch with a senior advisor, whose name was Ben.

Ben was very nice to me on the phone and he too agreed that the problem sounded real and was not normal for a powerful machine such as my 2014 Mac Pro. However, before referring the issue to engineering, he wanted me to try one other thing, which was to reinstall Mavericks (the OS that the Mac Pro came with) on a separate partition and to check if I could reproduce my issues there.

This took me a while, because of course I had to redownload the Mavericks installer from the App Store and create a bootable USB volume with it. (Ben wanted me to use Internet Restore for this, which would have neutralized my Mac for the duration of the download, i.e. at least two hours.)

With my Mavericks partition, I was above to confirm the following:

  1. There was no problem with drawing the blue highlighting behind the “Help” menu heading in the menu bar in Mavericks.
  2. The interruptions when scrolling down a Finder window with the contents of the /System/Library/Extensions/ folder with the Magic Mouse did also occur in Mavericks, so it wasn’t a new problem in Yosemite, just one that I had not noticed before.
  3. The recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process didn’t seem to occur in Mavericks.
  4. The lack of responsiveness of various UI controls, including menu headings and buttons for pop-up menus, didn’t exist in Mavericks.

In addition, through additional tests of my own, I was able to establish the following:

  1. The interruptions when scrolling down a Finder window with the contents of the /System/Library/Extensions/ folder only occurred with the Magic Mouse, and not with the old wired Apple Mouse, so it was a Magic Mouse-specific issue, probably unrelated to other responsiveness issues in Yosemite.
  2. The recurring addition of new log files in /private/var/log/asl/ involving the sandboxd process was much worse in the early build of OS X 10.10.2 that I had been testing as part of my involvement in the AppleSeed program than in the official 10.10.1 release. I still saw the problem on occasion in 10.10.1, but much less frequently. There was also no clear indication whether this had any link to responsiveness issues.
  3. The only situation where I did not see the problem with the drawing of the blue highlighting behind the “Help” menu heading in the menu bar in Yosemite was when I used the Yosemite-based Internet Restore service (while on the phone with Ben). But with all other versions of Yosemite that I tried, including on a clean partition with nothing else installed on it, I could see the problem.

Ben had given me his contact info, so I sent him an email explaining all this. At the same time, however, I stressed that the most important issue for me was that recurring, undesirable delay when clicking on various UI controls to bring down menus. Such a lack of responsiveness is unacceptable on a machine as powerful as a 2014 Mac Pro.

I am convinced that the problem is caused by Yosemite itself, and not by any incompatibility with third-party software. Since Ben didn’t get back to me right away, or even after I left a message on his voicemail a few days later, I took it upon myself to rebuild my entire startup volume from scratch.

You need to realize that this is a massive undertaking. Wiping the system volume and rebuilding everything involves hundreds of manual steps, not just to reinstall the software, but also either having to redo all the configuration of the software manually in the software itself (which involves trying to remember where you have to do to set this and that, given that settings are never always where you expect them to be) or manually copying all kinds of preference/configuration files from an backup of the old volume to the new.

But that’s exactly what I did. It took me hours, and I made sure I didn’t install anything that involved any kind of kernel extension or any other “questionable” (at least in the eyes of Apple’s engineers as I imagine them) software practices on the part of third-party developers. (This means that, even now, several days later, I am still without my beloved Default Folder X, for instance.)

It was materially impossible for me to the following:

  1. Install only one new piece of software, configure it and start using it.
  2. Continue using the entire system for several hours (if not days) with only that one new piece of software, and see if the responsiveness issue with the UI controls resurfaces.

I have far too many pieces of software that I use and need for my work to be able to do this. It would take me weeks. So, yes, I reinstalled things in batches. But I did try and do the above for the most “suspicious” pieces of software, i.e. for system-wide utilities such as Keyboard Maestro, LaunchBar, and Typinator. These particular pieces of software might be deemed “suspicious” by Apple’s engineers not because they involve kernel extensions or anything like that, but because they effectively act as an additional layer between the user and the machine, which intercepts and processes some interactions in order to automate specific actions. They are extremely important for my productivity and I cannot really imagine doing any substantial work on my machine without them.

Still, for about 48 hours I was reasonably optimistic that, through the rebuilding on my entire system from scratch, I had been able to eliminate that one responsiveness issue when clicking on UI controls that bring up menus.

And then yesterday afternoon I noticed it again. And again.

It might be deemed subtle and minor by some, but to me it’s obvious and extremely annoying. It is very simple to describe: I do a simple click (without holding the mouse button down) on a menu heading or a button in a window, and then nothing happens for two or three seconds, and then all of a sudden the menu that the click was supposed to cause to appear right away finally appears, but then immediately disappears again, before I have even had a chance to select a menu item in it.

And then of course I click on the same UI control again, and everything works fine.

I just do not understand how I can be the only one noticing this and finding it intolerable. I realize that we live in the age of mobile devices, where people “tap” instead of clicking, and are much more tolerant of unresponsiveness, because, with a finger tap, there is always a reasonable possibility that the tap was not accurate enough and that the system didn’t detect it.

But this is not the same. Clearly the system detects my click, since it does display the menu (albeit very briefly) after a couple of seconds. So the problem cannot be blamed on imperfect clicking skills on my part.

To me, it looks as if the UI control in question has been somehow “put to sleep” by the OS and take a couple of seconds to “wake up”.

Is that what is really going on here? If it is, there is no excuse for such a behaviour. On a desktop machine with an unlimited supply of power (unlike a battery-powered laptop), power-saving “features” that come at the expense of basic responsiveness are simply not acceptable, or should at the very least be optional.

Then again, my interpretation of the situation might be wrong. This particular problem might have nothing to do with power-saving features in OS X, and might be simply an unintentional bug of some kind. But if so, how come I seem to be the only one noticing it, and making a fuss about it? All I am doing is using readily available software on my system to do real-world work. If the problem was caused by a specific piece of software, I should be able to eliminate it by quitting that piece of software. But that does not seem to be the case. It seems that it is the cumulative effect of having multiple pieces of software running, even if they are not using significant amounts of CPU power, that is causing the responsiveness problem to surface.

After doing a clean install and completely rebuilding my OS X environment from scratch, how can any kind of specific software incompatibility be blamed as the source of the problem?

I also do not see how this could be a hardware issue. My Mac Pro works fine otherwise, and there are no responsiveness issues when typing text or doing other stuff that does not involve clicking on UI controls to bring up menus.

I just do not understand. And I don’t know what to do. Ben won’t respond to my emails and phone calls. Maybe he feels that, if he ignores me long enough, I will stop complaining and learn to accept the inevitability of this issue.

But I won’t. I will never find such a lack of responsiveness on my expensive 2014 Mac Pro acceptable. What recourse do I have, though? I don’t see how giving up on Apple products or boycotting them will help. I know enough about the alternatives to know that they would drive me even crazier on a daily basis. I already have to suffer through the obligation of having to use Microsoft Word for my work, for goodness’s sake. This complete piece of shit has an enormous number of responsiveness problems, even on a superfast 2014 Mac Pro, and here again nobody seems to care but me. What can I do? I have to use Word for my work. I do as much as I can to avoid it, but there is a limit.

So now I am supposed to accept that Apple is going down that same route and stuffing unresponsive software down our throats and that there’s nothing that I can do about it?

I will never, ever accept this. It is simply not right. But I do not know what else to do.

Now, if you’ll excuse me, I have work to do, and my rebuiding of my system is still far from complete and will still take me several more hours. I don’t know if you can tell, but I am pissed.