Hi Quinn, this is a fully patched 10.14.6. Thanks

No, I haven't figured out the issue yet.

Here: https://stackoverflow.com/questions/56595575/how-to-enable-a-background-thread-to-draw-to-nsview

I'm setting setCanDrawConcurrently to YES on my view. The graphics context calls executed from drawRect still act like noops when ran on a separate drawing thread. I can clearly see drawRect running on my drawing thread by dumping the thread ID, the current graphics context is not nil and seems valid, and I'm making sure to call flushGraphics at the end of drawRect, but still nothing appears on screen. This is very perplexing. The StackOverflow solution is about rendering backbuffers on a thread (which I already do in my case), but then let the main thread still perform the drawing of the backbuffers to the screen. This is not tolerable in my case as our main thread has historically been busy, enough to drop 40 frames out of 60. Could it be possible that setCanDrawConcurrently only gets AppKit to use background threads when it needs to refresh the view, and has nothing to do with spawning a separate drawing thread manually? If I dispatch the display to the main thread from my drawing thread then the screen updates, but at a refresh rate way too low:   dispatch_async(dispatch_get_main_queue(), ^{   self.needsDisplay = YES;  }); The drawing thread only pulls a backbuffer from a queue populated by a render thread. I basically loop around this code on my drawing thread: self.needsDisplay = YES; [self display]; My dev machine is on macOS 10.15.7