The MacOS application I'm working on renders using Metal when available, but falls back to using OpenGL via CAOpenGLLayer for older OS versions.In Mac OS 10. Mac OS 10.10 (Yosemite), when the window is full screen, the layer's canDrawInCGLContext:pixelFormat:forLayerTime:displayTime: method is called (and returns YES), but after the first frame, calls to drawInCGLContext:pixelFormat:forLayerTime:displayTime: do not happen.The same behaviour occurs whether the layer is set to asynchronous, or when using explicit calls to setNeedsDisplay.Drawing in a non-fullscreen window works as expected.A simplified test app using CAOpenGLLayer works as expected. The main app uses SDL for window management (but not rendering), which could be a complication.Mac OS 10.11 and up work as expected.Does anyone have any ideas about why drawInCGLContext would not be called when canDrawInCGLContext returns YES?(I don't have direct access to the test computer running Yosemite so debugging this is pretty roundabout.)Thanks,-- dwn

I just upgraded to Big Sur and now I can't resize the navigator pane in Xcode 12.3--a major problem when a project has a directory structure deeper than two levels. Other apps (Finder, Safari) don't seem affected. More information: Not all projects/workspaces are affected. The project that was is one generated using cmake, and re-generating that project has fixed the problem.

The Xcode 12.3 editor is deleting both characters in a pair of sequential braces/brackets/parentheses with a single press of the 'delete' key, even though brace matching is turned off in the preferences. Is there a new preference somewhere I can use to turn off this behaviour? It's extremely disruptive when typing quickly.

I have a C library that compiles to a framework for MacOS/iOS and to a static/shared library on other platforms. Since updating to Xcode 12 I've run into the warning about double-quoted headers in a framework umbrella header and I'd like to update the library to be more "correct", but doing so results in name/path conflicts for the library headers. When another project references the library, a header can be located via <framework/header.h>, yet when building the library that path is incorrect. That is, the path to the header within the project structure is not the same as when packaged as a framework (or, for instance, when installed to /usr/local/include). This is a problem with dependencies between library headers. Futhermore, when building, the project must use the version of the headers located within the project directory--not those previously installed in some system include path. According to the C spec, including via angle brackets is supposed to search for headers in the system include paths--not relative to the current directory--so how does using angle brackets in the umbrella header even work reliably in the first place? It feels like I'm missing something obvious, here.

I've run into a weird problem trying to use an XBox One Wireless gamepad via the GameController SDK. The controller works fine on two different Macs running Big Sur (and previously worked under Catalina), but is reported as a GCMicroGamepad on an iMac running Mojave. I can't seem to find a list of devices supported by the GameController framework, but I assumed the XBox One controller was a safe bet. Is this device not supported on the older OS?

I have a strange problem affecting two iMacs (Retina 5K, 27", late 2014) running MacOS Mojave 10.14.6. After the compture has been running for a while, some textures can either appear pure blue (i.e. #0000ffff) or become garbled in other ways. While I don't have physical access to the affected computers, I do have GPU trace from one that confirms that the texture data itself is definitely the problem. The affected textures are all loaded from disk via CGImage. Not all textures are affected, and those that are do not always show this behaviour--it appears to be specific to certain situations. Reloading the affected textures will sometimes correct it. Rebooting the computer seems to temporarily fix the problem, which suggests this may be an issue with the video driver or GPU. This doesn't seem to affect any of our other Macs, including my 2020 Macbook Pro 13" (Big Sur) and 2012 Macbook Air (Catalina). Any thoughts on what could cause this, or suggestions on how to investigate further?

I noticed the MTLDevice API for MacOS 11 includes an API to check for BC texture support (supportsBCTextureCompression), which suggests BC formats are not necessarily supported on some MacOS systems regardless of GPU family. This could obviously impact what textures need to be shipped with my application since I was planning on including only ASTC formats for iOS and BC formats for MacOS to help reduce the package size. I have a few questions around this: Under what circumstances are BC formats NOT supported on MacOS? What compressed formats are available on a MacOS system that doesn't support BC compression? Does a Catalyst app need different texture formats when running on iPadOS vs. MacOS? (This question is largely academic since I don't plan on shipping a Catalyst app.) Also, any links to documentation that outlines different scenarios would be greatly appreciated.

In Xcode 13, when pressing return on a line with a triple-slash comment, the editor automatically inserts another triple-slash on the new line. Also, it's still deleting both parentheses in a pair when I only delete the first one. Does anyone know how to turn this off? It's extremely disruptive.

I've run into two (possibly related) problems involving mipmaps in BC7 RGBA Unorm textures. The first, and more serious, is a crash when uploading the last mipmap level of a texture. Thus far this has only happened on two machines, both running Catalina. Also, only certain textures cause the crash, but there doesn't seem to be anything unusual about them. From the crash reports: MacOS 10.15.7 19H1519, Intel Graphics 4000 (this is from a debug, single-threaded build) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25cff33d CpuSwizzleBlt + 11667 1 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25ce7ca0 -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1387 2 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25ce7e2f -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 74 MacOS 10.15.7 19H1419, Intel Graphics 5000 (this is from a release, multi-threaded build) Thread 9 Crashed: 0  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2973b9c0 CpuSwizzleBlt + 9224 1  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2972714b -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1385 2  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff297272c3 -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 64 I'll post the full crash reports to Feedback Assistant. The second problem only happens on Mojave, and results in what looks like garbled pixel data in the mipmaps (I don't have access to the machine to do a frame capture). I can work around this issue by disabling mipmaps in the texture sampler. There are no Metal validation errors, and neither problem happens on Big Sur (I don't yet have a Monterey machine). Uncompressed textures are fine, as well, although mipmaps for those are generated on-the-fly rather than uploaded. Padding the source pixel data doesn't help, so the seg fault likely isn't caused by a too-large or unaligned read. Has anyone else run into problems with mipmaps in BC7 compressed textures?

I have two iMacs where MTLDevice.currentAllocatedSize is acting strange--the reported size keeps rising, despite periodically freeing resources to keep under MTLDevice.recommendedMaxWorkingSetSize. The affected iMacs are both late 2014 models running MacOS Big Sur 11.6, one with an AMD Radeon R9 M290X and the other with an AMD Radeon R9 M295X. So far none of our other Macs have shown this behaviour, which suggests this may be an API or driver problem. I do have the option of using my own resource size estimates, but that's likely not as accurate as what the system reports, assuming MTLDevice.currentAllocatedSize is working properly. Any suggestions?

I have a command line tool that zsh refuses to run when built for Apple Silicon or as a univerisal binary (the specific message is zsh: killed TOOL_NAME). I can only get it to run if I build it exclusively for Intel/Rosetta. Running/debugging from within Xcode works fine for any architecture. The tool is a very simple C/C++ unix command-line tool; it doesn't have any external dependencies beyond the C runtime and the C++ STL. I suspect something in code signing is going awry, but I've tried various team and certificate combinations without any luck. I've also tried enabling/disabling the app sandbox, also without any luck. (The app is not for distribution so it doesn't really need to be code signed at all.) Any suggestions?

The Leaks instrument is suddenly giving me the error "Required kernel recording resources are in use by another document." I see this has come up with Xcode 12 on iOS, but now it's happening when profiling a Mac application on Monterey 12.3.1 and Xcode 13.3. I get the same behaviour on a debug or release build. The Allocations instrument on its own also gives the same error. The Time Profiler intrument launches without issue. Regardless of the (useless) error, it's possible this is a signing issue, since Intruments is also constantly asking for a password when launching the process. Does anyone have any insight into what is causing this?

The application I'm working needs access to a shared network drive while in development. This nominally works, but every time the app is recompiled (so hundreds of times a day), I have to give it permission to access a network volume. For obvious reasons, that isn't helpful. Does anyone know how to grant network share access permanently? Barring that, is there a way to disable that security setting, preferably with a capability/entitlement, or at the system level as a last resort? (The app does have the proper credentials granted in System Preferences, but I presume its signature or something changes with each recompile.)

I'm seeing a strange rendering glitch with Metal rendering on (at least) two laptops, both are Intel MacBook Pro 13" 2020 with 4 Thunderbolt ports (my own is the i7 model). Thus far this is the only Mac model we've seen the issue on. The glitch results in a single-frame red pattern (see the attached image), but only when running full screen on the laptop display. It does not show when running in a window or in full screen on an external display. Even having an external display attached seems to prevent the problem. The glitch typically appears on frames where we do little to no rendering beyond clearing the color buffer, however I've been unable to isolate the glitch in a test application. The glitch also only happens when using the MTLPixelFormatRGBA8Unorm pixel format for the colour buffer. Switching to MTLPixelFormatRGBA16Float prevents it from happening. I've played around with the load/store states on the colour buffer, with various clear values, all with no success. Furthermore, I've managed to inspect the frame in a Metal GPU capture, and the color buffer in the capture is correct (cleared to black) even though the contents of the view are glitched. This leads me to think the problem may be in the CA compositing step, rather than in the Metal rendering itself. Any suggestions?

I have Mac OS application with several embedded frameworks. When debugging the application in recent versions of Xcode (comfirmed in 14.2) I am no longer able to inspect opaque C structs defined in a framework when the debugger has stopped in code belonging to the application or a different framework. The application and frameworks are all compiled by me as part of the application workspace, all have debugging enabled, and all are properly generating dSYM files. Does anyone know what might be going on? This is making debugging the framework code very difficult.