This question was answered on SO. Adding Martin R’s answer with his permission: You can use withUnsafeBufferPointer() to pass the address of the slice's element storage to the vDSP function: sliceOfBuffer.withUnsafeBufferPointer { bp in vDSP_vsortiD( bp.baseAddress!, sortedIndices, nil, UInt(sliceOfBuffer.count), vDSP.SortOrder.descending.rawValue ) } With respect to slicing the indices: It seems that one can pass sortedIndices + sliceOfBuffer.startIndex to the vDSP function. However, the documentation states that the indices must be initialized starting at zero, so I would not rely on that.

Solved by switching to loading via SCNScene(url:).

The Swit 5.7 application I’m working appears to have its @MainActor workload (which is always on the main thread) moved to the efficiency cores for no apparent reason, (only sometimes and randomly) resulting in very poor performance in rendering content in SceneKIT (lower than actual 10 FPS, all the while the instrumentation insist 60 FPS is what it is being rendered at). The app only moves back the main thread to performance cores after either one of these actions: background the app (switych to another app or the homescreen) then restore focus. pull down the semi transparent (glassy) control center curtain all the way down (has to be all the way down) then dismiss it. All non rendering code in the app executes on secondary threads using .userInteractive initiated DispatchQueue (afterwhich most code resumes on random secondary threads via awaits (async awaits everywhere) except for some code which updates the main thread parts (SceneKIT, SwiftUI stuff, etc) - variations of this: DispatchQueue.main.asyncAfter(deadline: .now() + duration, qos: .userInteractive, flags: .enforceQoS How do I force the main thread which does the rendering to stay on the performance cores at all times or at least only while redrawing? Possible answer: move as many secondary threads as possible lower to .userInitiated as they may have been competing with the main thread for priority. I don’t know how to trigger the behaviour to test this out.

Hi, I’m also working in Playgrounds on the iPad on a multi touch app. Did you figure this out?

Is there a way to enable “Supports Document Browser” for Swift Playgrounds projects?

Is NSWindow Cocoa? I can’t import it in Swift Playgounds. Is there another way to set contentAspectRatio for SwiftUI apps?

Limiting how many hard working threads withTaskGroup creates to the number of total cores minus 1 could be what worked to fix this - I haven’t experienced the issue since then. Which means work was automatically assigned or moved to performance cores and whatever was interfering (too much context switching? or smth with threads in another [system] process) could execute more smoothly on the less busier core.

withTaskGroup was calling multiple actors. Each actor (as of writing this) binds all its execution to a single thread.

In the playground console you should run PlaygroundPage.current.needsIndefiniteExecution = true after you import PlaygroundSupport to keep the program from terminating

@Graphics and Games Engineer Thank you, I anticipated your answer and I fully understand that recommendation. That said, is there a way to get PPI? (not considering Vision OS yet, but a virtual/fake PPI is good enough for compatibility, and would be desired in this case).