Mystery black title bar

I have a Cocoa app that uses an ordinary document window to display a progress bar. It has a text label that shows a message, and if the operation is taking a while, then a progress bar appears below the message.

One of my customers found that on his older Mac Pro desktop, the title bar is black (and the window title is invisible), on his MacBook Pro, it’s normal. Both are running OS X 10.11.

How could this be happening? It isn’t happening on any other windows in the app.

I see that in the IDE from time to time when it’s compiling plugins during the build process.

I have an App with a document type associated with it. When starting the App via opening the document, I have the same issue. Somehow, the heavy work reading/processing the document prevents the window to complete it’s drawing.
After trying calling .Refresh from different places I ended up using a 50ms CallLater/singleshot timer that calls the method doing the work.

This, and the initial issue, occurs when an application blocks the main thread’s event loop. The rough gist of things is that the window’s contents are marked as dirty but it doesn’t get redrawn and flushed until the event loop resumes.

This makes sense, but it’s odd that someone’s reporting it for the first time when this app has been running on much slower computers starting in 2009. Maybe it’s El Cap being slower in reading the file.

It certainly means I should take a look at what I can do to avoid blocking!


[quote=262468:@John McKernon]Maybe it’s El Cap being slower in reading the file.

It certainly means I should take a look at what I can do to avoid blocking![/quote]
It’s El Capitan iOS graphics system not working correctly.

There’s a WWDC video on what you can do about it as NOW it’s a problem. I’m still trying to get my head around it also, have all kinds of weird visual glitches since Yosemite.

Certainly the problem I have is that the OS tries to show the window, before the Open event has completed, so I’m still busy loading things and creating caches, whilst it decides “I’m going to show the user something already”, no wait! Bugger…

I’ve got to disagree on this. Apple has been telling developers not to block the main thread for as far back as I can remember on OS X.

It’s been real PITA, especially with Core Image’s Lazy loading. I don’t want the window to display UNTIL I’ve loaded and processed the preview, instead Apple thinks that my window should be shown before, which is what’s leading to some of the artifacts I’m seeing.

If I follow the WWDC video and prevent updates, the OS forcibly re-enables them (as noted in console). It waits one second, where as opening a document with a 50 mpx image takes 1.8 seconds.

When the OS displays the window before I’m ready, it shows a little preview in the bottom left hand corner, then once the app is running, it resizes to fill the area.

At the moment, it’s one of those things that I will have to work out before we ship. The other issue I managed to resolve today was dynamically laying out controls while NSAnimation was doing it’s thing. Even though I was setting the co-ordinates before the animation occurred, when the window was shown the animation had already happened and the controls were in the wrong place.

Any suggestions?