I have an NSImageView-based preview appex plugin for macOS in Objective-C. It's based off the sample template that you can add to an app. It completely makes it through preparePreviewOfFileAtURL, and I stuff pixel data into a CGImage, then that into an NSImage and that onto an NSImageView that is self.view from the storyboard. I can see all data via qlManager -p, since it will print error messages for caveman debugging. I have no idea and there are no docs on using the "Quick Look Simulator" which appears to do nothing. I set background color of the NSImageView.layer to red, and it shows up red. So I know the NSImageView is visible, just not the image that it also points to. About 30% of the time, only the red shows up, and the other 70% of the time nothing shows up in preview just smokey blurred version of the icons underneath in Finder. My only recourse, is to disable the extension list for the preview appex, and let the thumbnailer appex provide the preview. There are no samples of this for macOS, and the default templates aren't a working version of this either.

To minimize uptime, I am currently using two command buffers. One holds offscreen commands and is then committed. Then the second waits 20-30ms under heavy gpu use on nextDrawable, does a little work, and calls presentDrawable(which is drawable.present in addScheduledHandler). This whole setup seems less than ideal. On Android, Vulkan stalls very little on vkImageAquire, and mostly on vkQueuePresent, but that is after the command buffer is ended and submitted. Doing that present call on a thread is often suggested, but the command buffer is already complete and submitted to the gpu before that call. Metal stalls the commit of the command buffer from this fundamental architecture limitation. I would prefer to have a single command buffer here. The nextDrawable especially with frontBufferOnly set is really just a reference to a drawable, and shouldn't lead to such a long stall. This also makes using double buffering nearly impossible.

I'm getting "Bad Message 431" trying to access the forums from Chrome, so I'm using Safari instead. This is a thread with a ton of people hitting this problem. https://developer.apple.com/forums/thread/123657 I tracked it down to a bug in the validation layer. This happens with Apple's own sample code. RG16Unorm and other formats shouldn't be flagged as unsupported on a RDNA1 chip in the 16" MBP. Please also make are R16Unorm isn't flagged either. The Metal texture loader used in the sample seems to always pick the wrong format for loaded images (RG for a height map png?), with no way to control the format. This is the feedback assistant post on it. https://feedbackassistant.apple.com/feedback/9540775

There are no images on the basic primitives used in ModelIO that I've found so far. If these primitives are meant to be used by apps as starter content, then they should follow consistent modeling and uv wrapping rules. The sphere has uv coordinates where the u direction wraps counterclockwise. The capsule has the same problem. This is the opposite of the cube which fits u clockwise on each face. Solution was to flip x with 1-uv.x. The sphere reports 306 vertices on latest Big Sur, but after vertex 289 the rest of the vertex data is garbage data. The uv seam on the sphere is rotated by -45 degrees from the capsule. I had to flip the bitangent sign too in my app. This seemed to be reversed, but could be from shader issues. On my MBP 16" I'm getting uv's that are non-zero, but all zero derivatives. I don't know yet if this is from 2. Here's part of what I did to fix the mesh. This doesn't include the call to generate tangents and bitangent sign, and then flip the sign. mdlMesh = [MDLMesh newEllipsoidWithRadii:(vector_float3){0.5, 0.5, 0.5} radialSegments:16 verticalSegments:16 geometryType:MDLGeometryTypeTriangles inwardNormals:NO hemisphere:NO allocator:_metalAllocator]; float angle = M_PI * 0.5;   float2 cosSin = float2m(cos(angle), sin(angle));       {     mdlMesh.vertexDescriptor = _mdlVertexDescriptor;           id<MDLMeshBuffer> pos = mdlMesh.vertexBuffers[BufferIndexMeshPosition];     MDLMeshBufferMap *posMap = [pos map];     packed_float3* posData = (packed_float3*)posMap.bytes;           id<MDLMeshBuffer> normals = mdlMesh.vertexBuffers[BufferIndexMeshNormal];     MDLMeshBufferMap *normalsMap = [normals map];     packed_float3* normalData = (packed_float3*)normalsMap.bytes;           // vertexCount reports 306, but vertex 289+ are garbage     uint32_t numVertices = 289; // mdlMesh.vertexCount           for (uint32_t i = 0; i < numVertices; ++i) {       {         auto& pos = posData[i];                 // dumb rotate about Y-axis         auto copy = pos;                   pos.x = copy.x * cosSin.x - copy.z * cosSin.y;         pos.z = copy.x * cosSin.y + copy.z * cosSin.x;       }               {         auto& normal = normalData[i];         auto copy = normal;         normal.x = copy.x * cosSin.x - copy.z * cosSin.y;         normal.z = copy.x * cosSin.y + copy.z * cosSin.x;       }     }           // Hack - knock out all bogus vertices on the sphere     for (uint32_t i = numVertices; i < mdlMesh.vertexCount; ++i) {       auto& pos = posData[i];       pos.x = NAN;     }           }

The problem with ClampToEdge is that it stretches the outer strip of pixels even when uv goes outside [0,1]. So the typcial change is to use ClampToZero. The problem with ClampToZero/Border of 0 is that it pulls in black transparent color into images. What would be better is for this to double up the edge pixels of the texture (ClampToEdge), and only once uv exceeds 0,1 then bilerp the transparent color. Currently ClampToZero pulls in black and drops alpha at the edges of small images leading to poor edges of small textures.

How do you get a macOS 10.15 QuickLook extension to work? I added the provider from the Xcode template. The .appex file is in the app bundle under Contents/Plugins/foo-thumb.appex Can these Quicklook thumbnail providers override the system. So if macOS doesn't handle thumbnails for most types of ktx or any ktx2 files, can I override that with my own Quicklook plugin? I tried using qlmanage with -m, and all I see are qlgenerators in there. I don't see any .appex files registered or listed. So when I try this on ktx (org.krhonos.ktx) and ktx2 files (public.ktx2) a thumbnail isn't generated. qlmanager just seems to hang without the -x argument. And on the one file that worked, it pops up a thumbnail but I don't think it was generated by my appex. sudo qlmanage -t /Users/Foo/tests/Toof-a.ktx -c org.khronos.ktx -x Testing Quick Look thumbnails with files using server: /Users/Foo/tests/Toof-a.kt - force using content type UTI: org.khronos.ktx 2021-05-28 10:04:52.471 qlmanage[23522:4229132] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x984b, name = 'com.apple.tsm.portname' See /usr/include/servers/bootstrap_defs.h for the error codes. 2021-05-28 10:04:52.477 qlmanage[23522:4229132] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x6607, name = 'com.apple.coredrag' See /usr/include/servers/bootstrap_defs.h for the error codes. * No thumbnail created for /Users/Foo/tests/Toof-a.ktx Done producing thumbnails

So the underutilized boolean and counting occlusion queries look ideal for predicated rendering given no API support. This should work for 5s and above. generate a set of indexes in an instance buffer have occlusion query write an 8-byte value to that indexed buffer location read the buffer location from each instance. in vertex shader, lookup buffer value at index, and vertkill all instance vertices if 8-byte value is 0 Seems like this should work. This means the instance buffer is dynamically changed on the gpu after it is submitted. The buffer would need to be "private" space for gpu writes, but could be "shared" on iOS. Does this seem viable? One thing that would be useful as an extension to occlusion only write 0, and not any positive values to knock out instance counts. be able to write to 4 bytes instead of 8 to knock out ICB values being able to submit instanced boxes with queries on each one. The current queries require a scoped draw per box which is a lot of commands submitted

This seems to defeat the purpose of a developer forum, if no one can respond to posts except for Apple. Some of my posts are less than 1 month old? Even I don't check the forums that often, but it would be nice to respond to people's questions that have accumulated.

I have a single-windowed app that loads textures. I want to be able to switch textures to anything in the Open Recent menu item list that I add URLs into. When I launch the app, each recent menu item calls readFromURL once. But subsequent selection of the menu item does not. I can see the documents in the document controller increasing, so I know that is likely why this callback isn't called. If I return NO from readFromURL then it is called every time, but posts a dialog about the file failing to load. I want that behavior, but not the dialog. I'm not really using the NSDocuments created, but I needed this mechanism to get at the URL to load the data. I can't really remove documents from list, so I just let them accumulate but they basically just store the URL. What am I supposed to hook as a callback? Is there a switchToDocument callback hook/delegate?

When you use the simd classes like float3/matrix3x3 on Swift they are great. I can write and run code like this from existing math routines that are readily found on the web. let value = m[0][0] * v[0] When you try to do this in C++/ObjC, the code becomes this. This is not code readily found on the web, and is a big pain to convert. float value = m.columns[0][0] * v[0]; Can the float3x3 and other wrappers to simd_float3x3 provide an operator[] to the column and other operations like splatting since v[0] above pulls the data out of simd registers. We currently have to derive off the matrix classes, but it seems like functionality that should be provided in the C/C++ simd classes. A vector math library should promote better code readability than this. We seem to not be able to derive off the vector types which is an issue below. I also have code based on classes that takes 3 elements that suddenly has to convert to this less readble form. float3 v(x,y,z) - float3 v(simd_make_float3(x,y,z)) And then there's this code that should fill all values like init repeating in Swift. This is error prone in converting existing simd code to Accelerate simd. So then we try to wrap the float3, can't derive off them, and then lose all swizzling support, operators, etc. Then have to roll our own ops on that struct that holds a float3. What's the recommended way to make this more C++ like without more compiler support float3 v = {3} - 3,0,0 wasn't expecting that float3 v(3) doesn't compile v = {3,0,0} is completely different syntax, and doesn't line up with MSL and most simd libraries struct myfloat3 : float3 doesn't work struct myfloat3 { float3 v; - works, but loses swizzles, operators, etc explicit myfloat3(float value) myfloat3(float x, float y, float z) ... }

When we switched from the old to new build system, that broke all of our error/warning clickthrough to headers. These are reported as ../../folder/file.h but clicking on the messages doesn't bring up the offending line. The .cpp files clickthrough fine, since they are full paths. My understanding is that the old build system resolve these to full paths, and the new build system does not. What is the solution here? Our Visual Studio projects work and VC++ has a compile option /Fc to force full paths in all diagnostic message.

CMake calls through to xcodebuild clean, but this fails since custom build directories are set. The current workaround is to have to trash the entire CMake build folder. With many subprojects this then takes a long time to rebuild. Can Apple please fix this? Here I have a project with multiple targets (a fake workspace). CMake can only generate xcprojects and not xcworkspace files. Visual Studio and Android Studio both integrate CMake into the IDE. But building iOS and macOS universal apps is still not simple with CMake. Can Xcode team support CMake better in general? cmake --build . --target clean  xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment Command line invocation:   xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment User defaults from command line:   HideShellScriptEnvironment = YES note: Using new build system note: Building targets in parallel error: Could not delete `build/lib` because it was not created by the build system. error: Could not delete `build/app1` because it was not created by the build system. error: Could not delete `build/app2` because it was not created by the build system. warning: Refusing to delete `build` because it contains one of the projects in this workspace: `build/foo.xcodeproj`. CLEAN FAILED

The Adobe C++ plugin SDK are still using Rez to compile resources on macOS and winOS. But Rez build settings are missing from my newly created project. They exist in a legacy project. How does one re-enable this functionality. I don't know that Apple has offered an alternative to file-based resource generation, so removing this functionality seems premature. The help and man pages on Rez are missing a lot. What to supply for arch (x86_64)? Why do I have to supply the framework path to Xcode to find Carbon.r and CoreServices.r? Rez itself provides only the barest of command line usage details. For example, I couldn't get .r includes to work with -i or -s, but it works with -I. But the resulting .rsrc file that is generated by my command line efforts is 0 sized. The one built from Xcode is 1.5KB (correct). Also SIP was blocking all attempts to debug these plugins, but a workaround was found for that.

I see region support in MTLBuffer to MTLTexture upload calls, but I’d like to upload an entire level of same-sized mips in 1 call. Calling these routines once for every image x 2048 layers x every mip is a lot of commands. If I could do this once for each mip size, that seems more efficient, though a longer command for Metal to complete.

I was working on a macOS ObjC++ tool that allocated and then replaced a single MTLTexture, and noted that all of the textures were leaked. This project was built with CMake, and I found out the Xcode defaults ARC to off. ARC has been around long enough that I can't think of many ObjC or Swift projects that would work without it. This default should probably be changed. The workaround for now, is in all CMakeLists.txt files, to set the following:   XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC YES