Delve into the world of graphics and game development. Discuss creating stunning visuals, optimizing game mechanics, and share resources for game developers.

Posts under General subtopic

Post

Replies

Boosts

Views

Activity

PDFKit Page Rerender
I'm experiencing an issue with PDFKit where page.removeAnnotation(annotation) successfully removes the annotation from the page's data structure, but the PDFView no longer updates automatically to reflect the change visually. Issue Details: The annotation is removed (verified by checking page.annotations.count) The PDFView display doesn't refresh to show the removal This code was working correctly before and suddenly stopped working No code changes were made on my end
5
3
1.5k
45m
Request for higher hardware encoding resolution/performance on the future Mac desktop/laptop platforms for VR support.
Request: Mac media-engine headroom for 3840-per-eye stereo encoding to Apple Vision Pro We develop a Mac app that streams OpenXR VR applications, rendered on the Mac's GPU, to Apple Vision Pro as stereo video. The Mac encodes with VideoToolbox, as MV-HEVC (one layer per eye) or side-by-side HEVC. Vision Pro decodes the stream and presents it in an immersive space. We'd like to ask for future Mac hardware to support stereo encoding at Vision Pro-class resolution: 3840 pixels per eye at 90 fps. Why resolution matters without eye tracking Vision Pro does not give applications eye-tracking data. We understand and respect the privacy reasons. It does mean a streaming app can not use gaze-driven foveated encoding, which sends full detail where the wearer is looking and less elsewhere. Streaming solutions on other headsets use that to stay within their encoder budget. Without gaze data, every part of each eye's image has to be sent at full detail, so the only route to a sharper image is encoding more pixels. Today the encoder is where that stops. What we measured (tested on an M4 Max) M4 Max, macOS 27.0.1, hardware HEVC through VideoToolbox, synthetic frames at 200 Mbps, no frame reordering, RealTime off, speed prioritised, frames submitted at 90 Hz with at most 4 in flight, eye heights at 20:19. Results are frames per second, with median encode latency in brackets. MV-HEVC: 2048×1952 per eye: 90 fps (16 ms) 2240×2128 per eye: 90 fps (19 ms), the largest size that holds 90 2304×2192 per eye: 87 fps (46 ms) 3072×2928 per eye: 50 fps (79 ms) 3840×3648 per eye: 33 fps (121 ms) Side-by-side HEVC: 2048×1952 per eye: 90 fps (12 ms) 3072×2928 per eye: 90 fps (25 ms) 3200×3040 per eye: 90 fps (27 ms), the largest size that holds 90 3328×3168 per eye: 86 fps (46 ms) 3840×3648 per eye: 65 fps (61 ms) What the numbers show: One MV-HEVC session uses one media engine (about 0.92 Gpx/s at every size). The second engine sits idle: two MV-HEVC sessions at 3840 per eye run at the same time at 33 fps each. One single-layer HEVC session spreads across both engines (about 1.82 Gpx/s), but only while nothing else is encoding. With a second session open (we used a 1080p30 desktop share), it drops to one engine: 3072 per eye falls from 90 to 52 fps, and 3840 per eye from 65 to 33 fps. GPU load does not slow the media engine. We repeated the tests beside a synthetic GPU load using 7 to 9.6 ms of every 11.1 ms frame, as a VR title would, and every result was unchanged. The encoding window we actually have At 90 Hz a frame lasts 11.1 ms, and the VR application uses most of that rendering on the GPU. Rendering and encoding run in sequence for each frame, so every millisecond of encoding adds directly to the wearer's motion-to-photon latency, on top of the app's own frame. In practice we need two things from the encoder: Latency: finish each frame within about one frame period (around 11 ms), so the stream adds no more than one frame beyond the app. Today 2048 per eye MV-HEVC takes 16 ms, or about 1.5 frames. Headroom: run at no more than about 75 % of capacity. Real scenes vary in complexity, and near the limit latency climbs steeply (side-by-side HEVC goes from 27 ms at 3200 per eye to 46 ms at 3328 per eye). At 75 % load an M4 Max supports about 2000 per eye for MV-HEVC, which is the 2048 we ship today, and about 2800 per eye for side-by-side HEVC when no other session is running. 3840×3648 per eye at 90 fps is 2.52 Gpx/s. With the 25 % headroom, that is about 3.4 Gpx/s of sustained encode capacity: roughly 1.9× both M4 Max engines together, or 3.7× the single engine an MV-HEVC session gets today. For comparison, our Windows host encodes MV-HEVC at 3840×3648 per eye at 90 fps on a current desktop NVIDIA GPU, in about 11 ms per frame, by splitting the work across its encoder engines. Vision Pro decodes and presents that stream at 90 fps, so the headset handles this resolution. The gap is on the Mac's encoding side. What we don't know yet We do not yet know whether the Mac GPU can render VR titles at 3840 per eye at 90 fps; that will depend on the title. We can not usefully find out while the encoder limits us first, so in practice we ship MV-HEVC/HEVC at 2048 per eye by default. What we're asking for About 3.4 Gpx/s of HEVC / MV-HEVC encode capacity in future Mac media engines, enough for 3840×3648 per eye at 90 fps with headroom, plus room for a smaller second session such as a desktop share. MV-HEVC/HEVC sessions that can use more than one media engine on chips that have them. On current chips this alone would roughly double the stereo ceiling. A single-layer HEVC session that keeps its multi-engine split while another session is running, or a property to request that. If the platform can offer it, a privacy-preserving foveation path for streaming apps, where the system supplies a foveation region to the encoder without the app ever seeing raw gaze. If a VideoToolbox configuration already lets one MV-HEVC/HEVC session use both engines, we'd be glad to hear about it. We're happy to file a Feedback report with our test tool attached.
0
0
14
1h
WebGL linkProgram fails for every program in a Mac Catalyst WKWebView on macOS 27.3 beta
On macOS 27.3 beta (26C5035r), WebGL draws nothing in a WKWebView in a Mac Catalyst app. A WebGL2 context is created and shaders pass COMPILE_STATUS, but linkProgram fails for every program, with LINK_STATUS false and an empty program log. The same source file draws when built for My Mac. The same page also draws in Safari 27.3 and in the iOS 27.0 Simulator. Only the Mac Catalyst build fails. To reproduce, run a trivial vertex and fragment shader pair in a WKWebView, built for My Mac (Mac Catalyst): LINK_STATUS: false program log: "" pixel: 0, 0, 0, 0 getError: 1282 The unified log for the Catalyst app's com.apple.WebKit.GPU process shows this for each shader: (Metal) Metal Compiling Shader (Metal) Compiler failed to build request MTLCompilerService logs "Compilation BEGIN" for each request, then no "Compilation SUCCESS". The Metal source from WEBGL_debug_shaders is byte-identical in the Mac and Catalyst views, and with ANGLE's link placeholders filled in by hand it compiles in a Catalyst process, so the failure seems specific to the Catalyst GPU process. Signing, app sandbox, hardened runtime and a new bundle identifier make no difference. A macOS bundle loaded into the Catalyst process does not help, because its WKWebView is the Catalyst one. Sketchy Workaround: run the page in an AppKit WKWebView in a separate macOS helper process. FB25444425
0
0
31
9h
Get Desktop background image
In a WWDC 2019 "Advances in macOS Security" at 18:40 there is the following code func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionOnScreenOnly], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } to find the CGWindowID of the Desktop background. This works, but when you then try to get the CGImage for that CGWindowID with let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgWin, [.bestResolution]) cgImage does get a reference, however it's just a gray image. Not the Desktop picture. It's clear from the documentation that ScreenCaptureKit should be used. However, if used I get multiple warnings to the user, the most concerning one states: "App" would like to record this computer's screen and audio. This is not true! I do nothing with audio and to say a capture is a recording is also misleading. Is there way to achieve what use to work before macOS 27? Or a way to change/avoid this misleading warning? Is there a reason why this warning is needed for capturing the Desktop background where before it was explicitly allowed?
7
0
3.2k
20h
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
5
0
1.8k
21h
GameSaveSyncedDirectory.openDirectory() crashes in CloudDocs initUIApplicationWillResignActiveNotification
We use the GameSave framework to sync player save data to iCloud. Since iOS 27, our game crashes a few seconds after a cold launch, the first time it calls GameSaveSyncedDirectory.openDirectory(). We call the API only from the main actor, but the crash is on a cooperative thread inside GameSave: EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x400000000000bad0 libobjc.A.dylib objc_release CloudDocs initUIApplicationWillResignActiveNotification CloudDocs -[BRQuery _setQueryState:] CloudDocs -[BRQuery _runQuery] CloudDocs -[BRQuery executeWithOptions:] Foundation -[NSMetadataQuery startQuery] GameSave BundleUpdatesWaiter.initMetadataQuery() GameSave BundleUpdatesWaiter.init(bundleURL:) GameSave closure #1 in GameSyncedDirectoryHolder.allowReaders(for:)Other threads are inside the same BRQuery path at the same moment. The crash reproduces without GameSave: starting twoNSMetadataQuery objects at once on background threads in a fresh process crashes 94 times in 100 in the iOS 27.0 Simulator, and never on iOS 26.5, so this seems like a regression. Starting one query on a single thread never crashes. I've submitted a support request (FB25352978) so hopefully this will be looked at fairly soon - if anyone else runs into this it would be good to know!
3
0
597
6d
CGSetDisplayTransferByTable is broken on macOS Tahoe 26.4 RC (and 26.3.1) with MacBook M5 Pro, Max and Neo
The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)
18
7
8.3k
1w
EXC_BAD_ACCESS in SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace called from `-[NSScreen _notchFrame]` during display cycle (macOS 14.7.4, Intel MacBook Pro)
Our macOS app crashes intermittently on the main thread inside system frames only. No frame of our own code is in the crashed thread's stack. I would like to know whether others have seen this, and whether there is a known cause or workaround. Environment macOS 14.7.4 (23H420) MacBookPro16,1 (16-inch, 2019), Intel Core i7-9750H, dual GPU (Intel UHD Graphics 630 + AMD Radeon Pro 5300M, automatic graphics switching) Built-in display only, as far as we can tell. We have no record of an external display being connected. The same machine crashed 3 times in 7 days with this same crash signature. Crash Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000010a5f9008 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Time Since Wake: 4798 seconds VM Region Info: 0x10a5f9008 is not in any region. CoreAnimation 10a5f8000-10a5f9000 [4K] rw-/rwx ---> GAP OF 0x2000 BYTES CoreAnimation 10a5fb000-10a5fd000 [8K] r--/r-- Thread 0 Crashed: 0 SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace + 181 1 AppKit -[NSScreen _notchFrame] + 85 2 AppKit _NSScreenFrameByAdjustingFrameForNotch + 55 3 AppKit -[NSScreen _layoutFrame] + 130 4 AppKit -[NSScreen visibleFrame] + 47 5 AppKit -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 589 6 AppKit -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 37 7 AppKit -[NSWindow(NSWindow_Theme) _regionForOpaqueViewsModifiedForResizing:] + 53 8 AppKit -[NSWindow(NSWindow_Theme) _resetDragMargins] + 343 9 AppKit -[NSWindow(NSWindow_Theme) _resetDragMarginsIfNeeded] + 43 10 AppKit __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 375 11 AppKit NSDisplayCycleObserverInvoke + 140 12 AppKit NSDisplayCycleFlush + 878 13 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 95 14 QuartzCore CA::Transaction::commit() + 377 15 AppKit -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:preCommitHandler:completionHandler:] + 336 ...What we know The faulting address is just past a mapped 4K CoreAnimation region, which suggests a stale pointer into a dynamically mapped region. Near the faulting instruction there is a loop that advances by 0x14 bytes per iteration, which might be a table walk. This is our reading of the disassembly only, not confirmed. About 1 second before the crash, our app closed a secondary window (a standalone chat window). This is the only UI action we see just before the crash, and it happened once, so we cannot say it is the trigger. The crash is not tied to a specific app feature, and it was not right after wake (about 80 minutes after the last wake). Separately, we see crashes on other Intel Macs inside SkyLight called from NSDisplayTiming, across macOS 13 to 26, with the same kind of "address outside any mapped region" fault. We believe they may share a root cause, but we have not proven it. Questions Has anyone seen _notchFrame / SLSWindowServerClientManagedDisplayGetCurrentSpace crashing like this, especially on a Mac with no physical notch? Is -[NSWindow _resetDragMargins] known to read screen geometry at a time when the display configuration or active space can change? Is there anything an app can do (for example, when and how it closes windows, or where it reads NSScreen.visibleFrame) to avoid this, or is this a system bug that should go to Feedback Assistant? I can share the full crash report if it helps. I'll also file a Feedback and post the FB number here.
1
0
532
1w
PHASE occluder silences direct sound instead of muffling it
I’m using PHASE for an outdoor soundscape with only .directPathTransmission enabled. A point source and listener are 2 metres apart. Between them is a PHASEOccluder built from a 2 × 2 × 0.02 metre MDLMesh box, with a .cardboard material assigned to every shape element. Without the occluder, the sound is loud. With it, the sound is completely inaudible. Switching to .glass and setting the sampler’s cullOption to .doNotCull makes no audible difference. This happens on both iOS Simulator and a physical iPhone. Adding .lateReverb produces faint audible sound, but room reverb is inappropriate for this outdoor scene and doesn’t establish whether direct transmission works. Is this expected attenuation, or is additional configuration required to hear muffled sound through an occluder? Is there a working sample demonstrating material-dependent transmission with reverb disabled?
3
1
2.0k
1w
NSOpenGLView / NSOpenGLContext setView: get no drawable on macOS 15.8.2 RC (24H219), windows render blank (FB25133383)
After updating a MacBook Pro (M1 Pro) from macOS 15.8 to the 15.8.2 release candidate (24H219), every OpenGL context that is attached to a window has no default framebuffer. NSOpenGLView and -[NSOpenGLContext setView:] are both affected, so anything drawn that way shows a blank window. I filed FB25133383 with a minimal sample, kernel log and call trace. Symptoms kCGLCPHasDrawable is 0, glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219), and glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506). For every attach attempt the kernel logs: (IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N CGLSetSurface returns kCGLBadDrawable (10005). Stepping through it, CGSBindSurface succeeds and the IOGPU user-client call then fails with kIOReturnBadArgument. What still works Offscreen FBOs in the same context. CAOpenGLLayer and NSOpenGLLayer render correctly in the same process. Only the window-surface path is broken. Minimal sample (public API only) // clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro #define GL_SILENCE_DEPRECATION 1 #import <Cocoa/Cocoa.h> #import <OpenGL/OpenGL.h> #import <OpenGL/gl.h> #import <OpenGL/glext.h> @interface ReproView : NSOpenGLView @end @implementation ReproView - (void)drawRect:(NSRect)dirtyRect { NSOpenGLContext *ctx = [self openGLContext]; [ctx makeCurrentContext]; GLint hasDrawable = -1; CGLGetParameter(ctx.CGLContextObj, kCGLCPHasDrawable, &hasDrawable); GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER); glClearColor(0, 1, 0, 1); glClear(GL_COLOR_BUFFER_BIT); GLenum err = glGetError(); printf("hasDrawable=%d status=0x%x glError=0x%x\n", hasDrawable, status, err); fflush(stdout); [ctx flushBuffer]; } @end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0; } Expected: a green square and hasDrawable=1 status=0x8cd5 glError=0x0. On 24H219: nothing is drawn and it prints hasDrawable=0 status=0x8219 glError=0x506. Scope Same result for arm64 and x86_64 under Rosetta, layer-backed or not, main thread or background thread. Affected on my Mac: Sony Imaging Edge Desktop Viewer (NSOpenGLView), DJI Studio (Qt 6, NSOpenGLContext) and its Quick Look extension. Public reports with the same symptom on 24H219: kitty #10645, Alacritty #9067, Godot #124311, Bambu Studio #12530 (all on GitHub). They cover M1, M4, M4 Pro and M4 Max, and the Alacritty report says 15.8.1 was fine. Questions Is this a known issue in the 15.8.2 RC, and will it be fixed before 15.8.2 ships? Is anyone seeing it on the macOS 26.7.2 RC or the 27.2 beta? Workaround for developers in the meantime: render into an IOSurface-backed FBO and present that surface in a CALayer, or use CAOpenGLLayer.
8
4
22k
2w
macOS 27.2 RC (26B118) Built-in display canvas cropped with black bar at bottom-right after login
Description: MacBook Air M5, using only built-in display. The login window renders full screen normally. After logging into desktop session, the display canvas gets cropped with a black bar on the bottom-right corner. This issue is reproducible in Safe Mode and with a brand-new admin user account. No third-party display or window management software installed. Suspected WindowServer display coordinate calculation bug within user session. Environment Device: MacBook Air M5 OS: macOS 27.2 RC (26B118) Display: Built-in display only, no external monitor Reproduction steps Boot to login window, display works fine Log into desktop session Display canvas cropped, black bar appears at bottom-right
1
0
1k
2w
M5 Pro external display pipeline width limits and native HiDPI support
Hello Apple Engineering Team, I would like to clarify a technical question regarding the external display architecture of the M5 Pro MacBook Pro. I use a single ultrawide monitor with a native resolution of 3440 × 1440. To achieve true 2× HiDPI rendering at this logical resolution, macOS would need to render a framebuffer of 6880 × 2880. Third-party diagnostic tools and firmware reverse-engineering reports appear to indicate that M5 Pro has display-pipeline source-width limits of 6720 and 7680 pixels. Could you please clarify the following? Are these reported source-width limits accurate for the M5 Pro? Can macOS assign a single external display to the display pipeline that supports a 7680-pixel source width? Is there a supported way to influence or change this pipeline allocation, such as changing the connection port, connection order, or display configuration? Can a single 3440 × 1440 external monitor use native 2× HiDPI rendering (6880 × 2880) on the M5 Pro without virtual-display mirroring? If this configuration is unsupported, is the limitation imposed by hardware, firmware, or macOS display allocation policy? I understand that Apple may not disclose all internal implementation details. Any clarification regarding supported configurations or known limitations would be greatly appreciated. Thank you.
0
0
501
2w
Public API for system-wide SDR luminance control on built-in XDR?
I am investigating whether a macOS display utility can adjust the luminance of normal SDR desktop content system-wide, including other apps, on the built-in Liquid Retina XDR display of a 2021 M1 Max MacBook Pro. Is there a documented public API, or combination of public APIs, for this scope? The research target is SDR white around 1000 cd/m² while retaining HDR highlight capability, where supported by the hardware and OS. This is a feasibility question, not a claim that this output has been achieved or is supported. The approach must preserve OS color management and respect thermal, power and brightness limits, including protective dimming. I am not seeking gamma-table changes, screen capture and HDR re-display, private APIs, or bypasses of system protections. I understand that enabling EDR for an app's own layer is different from controlling ordinary SDR content in other apps. I am specifically asking about the latter. If this is supported, could you point to the API names, primary documentation, applicable macOS versions and hardware limitations? If it is not supported through public APIs, an explicit clarification would also be helpful.
2
0
1.4k
3w
ScreenCaptureKit is NOT a full replacement for CGWindowListCreateImage
My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } which returns [CGWindowID] of all the Desktop background/wallpaper windows. Then for any one, say cgID, a simple let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgID, [.bestResolution]) gave an CGImage which then can be applied to my custom NSWindow. No where is TCC triggered. All is great. I followed Apple's ideas about Security and Privacy since I'm only using the data I need (i.e. [CGWindowID]) and the data is only used during execution. Never saved or shared. macOS 27 beta 4 and beyond broke CGWindowListCreateImage(...). It compiles and when called it returns some gray image. Documentation tells me to use ScreenCaptureKit. The newest versions of ScreenCaptureKit introduce SCScreenshotManager.captureImage(contentFilter:, configuration) which can return a CGImage of the CGWindowID. Here is when the problem occurs. To capture that CGWindowID CGImage, one would use SCContentFilter(desktopIndependentWindow: desktopWindow) but to get desktopWindow you first need to find the SCWindow that corresponds to CGWindowID. You can grab a set of SCWindow with SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: false) But when any method of SCShareableContent is called, TCC throws up this warning I do not want this. Too many permissions are being granted. I only want the [CGWindowID] of the Desktop background/wallpaper. This, if the user grants, gives me much more which is bad for Security and Privacy. One way to avoid the TCC in ScreenCaptureKit is to use the new SCContentSharingPicker.shared. This allows the user to pick what they want to share. I first tried var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.multipleWindows, .singleWindow] but the picker does not allow the user to select the Desktop background/wallpaper. Using var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.singleDisplay] also doesn't give me Desktop background/wallpaper access. Trying to use [.singleApplication] and limiting the choices to WindowServer (what SCWindow claims is the owner) also doesn't allow picking of the Desktop background/wallpaper. So, is it true to get access to the Desktop background/wallpaper CGWindowID's CGImage, I must have the user give me full access via TCC? Please tell me of a work around. The obvious fix is on Apple's side. The corresponding list of [SCWindow] corresponding to [CGWindowID] should always be included in SCContentFilter.includedWindows. Or simply leave them out of the TCC domain as before.
2
0
603
4w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
6
2
2.7k
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
3
1
1.9k
Sep ’26
Times New Roman superscript and Unicode fallback font
I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.
5
0
1.4k
Sep ’26
Core Animation Background Thread CATransaction
Hey everyone 👋 I'm trying to initialize a part of a CALayer hierarchy on a background thread and then attach the root of that hierarchy to a CALayer that backs a UIView. The motivation is to keep the main thread responsive when constructing a complex layer hierarchy. This isn't a case where I'm creating two or three layers and then switching back to the main thread. The hierarchy can potentially contain a large number of layers, with animations being created/configured for those layers as well. My first approach was to create and configure the layers entirely on a background thread. While the output might be the expected one (not always), CoreAnimation emits an assertion along the lines of: "Modifications to the layer tree from a background thread may not be committed" (or something like this). This makes sense to me if implicit CATransaction is thread-local. In that case, the implicit transaction opened by the layer modification on the background thread would not be part of the transaction that is already open on the main thread. Therefore, committing the main-thread transaction would not commit the changes made on the background thread. My second approach was to explicitly create and commit a CATransaction on the background thread. This appears to be accepted by Core Animation's threading model, but I'm seeing unreliable results. Sometimes parts of the hierarchy are missing, and in other cases the hierarchy is present but the animations don't appear to run at all. I do understand that this is private behavior of the framework, but I wanted to know if what I am trying to achieve is possible and, if so, what the solution would be (obviously if you can share this information). Besides this, I would also like to know what behavior CATransactions have when they are created on different threads. What I mean by this is that the transactions work as a stack, and the changes are committed when the stack is empty. Does this behavior still apply when having transactions on different threads? Any weird behaviours that might appear between transactions operated on main vs background threads? Thank you! Vlad.
7
0
1.2k
Sep ’26
PDFKit Page Rerender
I'm experiencing an issue with PDFKit where page.removeAnnotation(annotation) successfully removes the annotation from the page's data structure, but the PDFView no longer updates automatically to reflect the change visually. Issue Details: The annotation is removed (verified by checking page.annotations.count) The PDFView display doesn't refresh to show the removal This code was working correctly before and suddenly stopped working No code changes were made on my end
Replies
5
Boosts
3
Views
1.5k
Activity
45m
Request for higher hardware encoding resolution/performance on the future Mac desktop/laptop platforms for VR support.
Request: Mac media-engine headroom for 3840-per-eye stereo encoding to Apple Vision Pro We develop a Mac app that streams OpenXR VR applications, rendered on the Mac's GPU, to Apple Vision Pro as stereo video. The Mac encodes with VideoToolbox, as MV-HEVC (one layer per eye) or side-by-side HEVC. Vision Pro decodes the stream and presents it in an immersive space. We'd like to ask for future Mac hardware to support stereo encoding at Vision Pro-class resolution: 3840 pixels per eye at 90 fps. Why resolution matters without eye tracking Vision Pro does not give applications eye-tracking data. We understand and respect the privacy reasons. It does mean a streaming app can not use gaze-driven foveated encoding, which sends full detail where the wearer is looking and less elsewhere. Streaming solutions on other headsets use that to stay within their encoder budget. Without gaze data, every part of each eye's image has to be sent at full detail, so the only route to a sharper image is encoding more pixels. Today the encoder is where that stops. What we measured (tested on an M4 Max) M4 Max, macOS 27.0.1, hardware HEVC through VideoToolbox, synthetic frames at 200 Mbps, no frame reordering, RealTime off, speed prioritised, frames submitted at 90 Hz with at most 4 in flight, eye heights at 20:19. Results are frames per second, with median encode latency in brackets. MV-HEVC: 2048×1952 per eye: 90 fps (16 ms) 2240×2128 per eye: 90 fps (19 ms), the largest size that holds 90 2304×2192 per eye: 87 fps (46 ms) 3072×2928 per eye: 50 fps (79 ms) 3840×3648 per eye: 33 fps (121 ms) Side-by-side HEVC: 2048×1952 per eye: 90 fps (12 ms) 3072×2928 per eye: 90 fps (25 ms) 3200×3040 per eye: 90 fps (27 ms), the largest size that holds 90 3328×3168 per eye: 86 fps (46 ms) 3840×3648 per eye: 65 fps (61 ms) What the numbers show: One MV-HEVC session uses one media engine (about 0.92 Gpx/s at every size). The second engine sits idle: two MV-HEVC sessions at 3840 per eye run at the same time at 33 fps each. One single-layer HEVC session spreads across both engines (about 1.82 Gpx/s), but only while nothing else is encoding. With a second session open (we used a 1080p30 desktop share), it drops to one engine: 3072 per eye falls from 90 to 52 fps, and 3840 per eye from 65 to 33 fps. GPU load does not slow the media engine. We repeated the tests beside a synthetic GPU load using 7 to 9.6 ms of every 11.1 ms frame, as a VR title would, and every result was unchanged. The encoding window we actually have At 90 Hz a frame lasts 11.1 ms, and the VR application uses most of that rendering on the GPU. Rendering and encoding run in sequence for each frame, so every millisecond of encoding adds directly to the wearer's motion-to-photon latency, on top of the app's own frame. In practice we need two things from the encoder: Latency: finish each frame within about one frame period (around 11 ms), so the stream adds no more than one frame beyond the app. Today 2048 per eye MV-HEVC takes 16 ms, or about 1.5 frames. Headroom: run at no more than about 75 % of capacity. Real scenes vary in complexity, and near the limit latency climbs steeply (side-by-side HEVC goes from 27 ms at 3200 per eye to 46 ms at 3328 per eye). At 75 % load an M4 Max supports about 2000 per eye for MV-HEVC, which is the 2048 we ship today, and about 2800 per eye for side-by-side HEVC when no other session is running. 3840×3648 per eye at 90 fps is 2.52 Gpx/s. With the 25 % headroom, that is about 3.4 Gpx/s of sustained encode capacity: roughly 1.9× both M4 Max engines together, or 3.7× the single engine an MV-HEVC session gets today. For comparison, our Windows host encodes MV-HEVC at 3840×3648 per eye at 90 fps on a current desktop NVIDIA GPU, in about 11 ms per frame, by splitting the work across its encoder engines. Vision Pro decodes and presents that stream at 90 fps, so the headset handles this resolution. The gap is on the Mac's encoding side. What we don't know yet We do not yet know whether the Mac GPU can render VR titles at 3840 per eye at 90 fps; that will depend on the title. We can not usefully find out while the encoder limits us first, so in practice we ship MV-HEVC/HEVC at 2048 per eye by default. What we're asking for About 3.4 Gpx/s of HEVC / MV-HEVC encode capacity in future Mac media engines, enough for 3840×3648 per eye at 90 fps with headroom, plus room for a smaller second session such as a desktop share. MV-HEVC/HEVC sessions that can use more than one media engine on chips that have them. On current chips this alone would roughly double the stereo ceiling. A single-layer HEVC session that keeps its multi-engine split while another session is running, or a property to request that. If the platform can offer it, a privacy-preserving foveation path for streaming apps, where the system supplies a foveation region to the encoder without the app ever seeing raw gaze. If a VideoToolbox configuration already lets one MV-HEVC/HEVC session use both engines, we'd be glad to hear about it. We're happy to file a Feedback report with our test tool attached.
Replies
0
Boosts
0
Views
14
Activity
1h
WebGL linkProgram fails for every program in a Mac Catalyst WKWebView on macOS 27.3 beta
On macOS 27.3 beta (26C5035r), WebGL draws nothing in a WKWebView in a Mac Catalyst app. A WebGL2 context is created and shaders pass COMPILE_STATUS, but linkProgram fails for every program, with LINK_STATUS false and an empty program log. The same source file draws when built for My Mac. The same page also draws in Safari 27.3 and in the iOS 27.0 Simulator. Only the Mac Catalyst build fails. To reproduce, run a trivial vertex and fragment shader pair in a WKWebView, built for My Mac (Mac Catalyst): LINK_STATUS: false program log: "" pixel: 0, 0, 0, 0 getError: 1282 The unified log for the Catalyst app's com.apple.WebKit.GPU process shows this for each shader: (Metal) Metal Compiling Shader (Metal) Compiler failed to build request MTLCompilerService logs "Compilation BEGIN" for each request, then no "Compilation SUCCESS". The Metal source from WEBGL_debug_shaders is byte-identical in the Mac and Catalyst views, and with ANGLE's link placeholders filled in by hand it compiles in a Catalyst process, so the failure seems specific to the Catalyst GPU process. Signing, app sandbox, hardened runtime and a new bundle identifier make no difference. A macOS bundle loaded into the Catalyst process does not help, because its WKWebView is the Catalyst one. Sketchy Workaround: run the page in an AppKit WKWebView in a separate macOS helper process. FB25444425
Replies
0
Boosts
0
Views
31
Activity
9h
Get Desktop background image
In a WWDC 2019 "Advances in macOS Security" at 18:40 there is the following code func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionOnScreenOnly], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } to find the CGWindowID of the Desktop background. This works, but when you then try to get the CGImage for that CGWindowID with let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgWin, [.bestResolution]) cgImage does get a reference, however it's just a gray image. Not the Desktop picture. It's clear from the documentation that ScreenCaptureKit should be used. However, if used I get multiple warnings to the user, the most concerning one states: "App" would like to record this computer's screen and audio. This is not true! I do nothing with audio and to say a capture is a recording is also misleading. Is there way to achieve what use to work before macOS 27? Or a way to change/avoid this misleading warning? Is there a reason why this warning is needed for capturing the Desktop background where before it was explicitly allowed?
Replies
7
Boosts
0
Views
3.2k
Activity
20h
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
Replies
5
Boosts
0
Views
1.8k
Activity
21h
GameSaveSyncedDirectory.openDirectory() crashes in CloudDocs initUIApplicationWillResignActiveNotification
We use the GameSave framework to sync player save data to iCloud. Since iOS 27, our game crashes a few seconds after a cold launch, the first time it calls GameSaveSyncedDirectory.openDirectory(). We call the API only from the main actor, but the crash is on a cooperative thread inside GameSave: EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x400000000000bad0 libobjc.A.dylib objc_release CloudDocs initUIApplicationWillResignActiveNotification CloudDocs -[BRQuery _setQueryState:] CloudDocs -[BRQuery _runQuery] CloudDocs -[BRQuery executeWithOptions:] Foundation -[NSMetadataQuery startQuery] GameSave BundleUpdatesWaiter.initMetadataQuery() GameSave BundleUpdatesWaiter.init(bundleURL:) GameSave closure #1 in GameSyncedDirectoryHolder.allowReaders(for:)Other threads are inside the same BRQuery path at the same moment. The crash reproduces without GameSave: starting twoNSMetadataQuery objects at once on background threads in a fresh process crashes 94 times in 100 in the iOS 27.0 Simulator, and never on iOS 26.5, so this seems like a regression. Starting one query on a single thread never crashes. I've submitted a support request (FB25352978) so hopefully this will be looked at fairly soon - if anyone else runs into this it would be good to know!
Replies
3
Boosts
0
Views
597
Activity
6d
CGSetDisplayTransferByTable is broken on macOS Tahoe 26.4 RC (and 26.3.1) with MacBook M5 Pro, Max and Neo
The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)
Replies
18
Boosts
7
Views
8.3k
Activity
1w
EXC_BAD_ACCESS in SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace called from `-[NSScreen _notchFrame]` during display cycle (macOS 14.7.4, Intel MacBook Pro)
Our macOS app crashes intermittently on the main thread inside system frames only. No frame of our own code is in the crashed thread's stack. I would like to know whether others have seen this, and whether there is a known cause or workaround. Environment macOS 14.7.4 (23H420) MacBookPro16,1 (16-inch, 2019), Intel Core i7-9750H, dual GPU (Intel UHD Graphics 630 + AMD Radeon Pro 5300M, automatic graphics switching) Built-in display only, as far as we can tell. We have no record of an external display being connected. The same machine crashed 3 times in 7 days with this same crash signature. Crash Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000010a5f9008 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Time Since Wake: 4798 seconds VM Region Info: 0x10a5f9008 is not in any region. CoreAnimation 10a5f8000-10a5f9000 [4K] rw-/rwx ---> GAP OF 0x2000 BYTES CoreAnimation 10a5fb000-10a5fd000 [8K] r--/r-- Thread 0 Crashed: 0 SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace + 181 1 AppKit -[NSScreen _notchFrame] + 85 2 AppKit _NSScreenFrameByAdjustingFrameForNotch + 55 3 AppKit -[NSScreen _layoutFrame] + 130 4 AppKit -[NSScreen visibleFrame] + 47 5 AppKit -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 589 6 AppKit -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 37 7 AppKit -[NSWindow(NSWindow_Theme) _regionForOpaqueViewsModifiedForResizing:] + 53 8 AppKit -[NSWindow(NSWindow_Theme) _resetDragMargins] + 343 9 AppKit -[NSWindow(NSWindow_Theme) _resetDragMarginsIfNeeded] + 43 10 AppKit __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 375 11 AppKit NSDisplayCycleObserverInvoke + 140 12 AppKit NSDisplayCycleFlush + 878 13 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 95 14 QuartzCore CA::Transaction::commit() + 377 15 AppKit -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:preCommitHandler:completionHandler:] + 336 ...What we know The faulting address is just past a mapped 4K CoreAnimation region, which suggests a stale pointer into a dynamically mapped region. Near the faulting instruction there is a loop that advances by 0x14 bytes per iteration, which might be a table walk. This is our reading of the disassembly only, not confirmed. About 1 second before the crash, our app closed a secondary window (a standalone chat window). This is the only UI action we see just before the crash, and it happened once, so we cannot say it is the trigger. The crash is not tied to a specific app feature, and it was not right after wake (about 80 minutes after the last wake). Separately, we see crashes on other Intel Macs inside SkyLight called from NSDisplayTiming, across macOS 13 to 26, with the same kind of "address outside any mapped region" fault. We believe they may share a root cause, but we have not proven it. Questions Has anyone seen _notchFrame / SLSWindowServerClientManagedDisplayGetCurrentSpace crashing like this, especially on a Mac with no physical notch? Is -[NSWindow _resetDragMargins] known to read screen geometry at a time when the display configuration or active space can change? Is there anything an app can do (for example, when and how it closes windows, or where it reads NSScreen.visibleFrame) to avoid this, or is this a system bug that should go to Feedback Assistant? I can share the full crash report if it helps. I'll also file a Feedback and post the FB number here.
Replies
1
Boosts
0
Views
532
Activity
1w
PHASE occluder silences direct sound instead of muffling it
I’m using PHASE for an outdoor soundscape with only .directPathTransmission enabled. A point source and listener are 2 metres apart. Between them is a PHASEOccluder built from a 2 × 2 × 0.02 metre MDLMesh box, with a .cardboard material assigned to every shape element. Without the occluder, the sound is loud. With it, the sound is completely inaudible. Switching to .glass and setting the sampler’s cullOption to .doNotCull makes no audible difference. This happens on both iOS Simulator and a physical iPhone. Adding .lateReverb produces faint audible sound, but room reverb is inappropriate for this outdoor scene and doesn’t establish whether direct transmission works. Is this expected attenuation, or is additional configuration required to hear muffled sound through an occluder? Is there a working sample demonstrating material-dependent transmission with reverb disabled?
Replies
3
Boosts
1
Views
2.0k
Activity
1w
NSOpenGLView / NSOpenGLContext setView: get no drawable on macOS 15.8.2 RC (24H219), windows render blank (FB25133383)
After updating a MacBook Pro (M1 Pro) from macOS 15.8 to the 15.8.2 release candidate (24H219), every OpenGL context that is attached to a window has no default framebuffer. NSOpenGLView and -[NSOpenGLContext setView:] are both affected, so anything drawn that way shows a blank window. I filed FB25133383 with a minimal sample, kernel log and call trace. Symptoms kCGLCPHasDrawable is 0, glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219), and glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506). For every attach attempt the kernel logs: (IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N CGLSetSurface returns kCGLBadDrawable (10005). Stepping through it, CGSBindSurface succeeds and the IOGPU user-client call then fails with kIOReturnBadArgument. What still works Offscreen FBOs in the same context. CAOpenGLLayer and NSOpenGLLayer render correctly in the same process. Only the window-surface path is broken. Minimal sample (public API only) // clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro #define GL_SILENCE_DEPRECATION 1 #import <Cocoa/Cocoa.h> #import <OpenGL/OpenGL.h> #import <OpenGL/gl.h> #import <OpenGL/glext.h> @interface ReproView : NSOpenGLView @end @implementation ReproView - (void)drawRect:(NSRect)dirtyRect { NSOpenGLContext *ctx = [self openGLContext]; [ctx makeCurrentContext]; GLint hasDrawable = -1; CGLGetParameter(ctx.CGLContextObj, kCGLCPHasDrawable, &hasDrawable); GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER); glClearColor(0, 1, 0, 1); glClear(GL_COLOR_BUFFER_BIT); GLenum err = glGetError(); printf("hasDrawable=%d status=0x%x glError=0x%x\n", hasDrawable, status, err); fflush(stdout); [ctx flushBuffer]; } @end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0; } Expected: a green square and hasDrawable=1 status=0x8cd5 glError=0x0. On 24H219: nothing is drawn and it prints hasDrawable=0 status=0x8219 glError=0x506. Scope Same result for arm64 and x86_64 under Rosetta, layer-backed or not, main thread or background thread. Affected on my Mac: Sony Imaging Edge Desktop Viewer (NSOpenGLView), DJI Studio (Qt 6, NSOpenGLContext) and its Quick Look extension. Public reports with the same symptom on 24H219: kitty #10645, Alacritty #9067, Godot #124311, Bambu Studio #12530 (all on GitHub). They cover M1, M4, M4 Pro and M4 Max, and the Alacritty report says 15.8.1 was fine. Questions Is this a known issue in the 15.8.2 RC, and will it be fixed before 15.8.2 ships? Is anyone seeing it on the macOS 26.7.2 RC or the 27.2 beta? Workaround for developers in the meantime: render into an IOSurface-backed FBO and present that surface in a CALayer, or use CAOpenGLLayer.
Replies
8
Boosts
4
Views
22k
Activity
2w
macOS 27.2 RC (26B118) Built-in display canvas cropped with black bar at bottom-right after login
Description: MacBook Air M5, using only built-in display. The login window renders full screen normally. After logging into desktop session, the display canvas gets cropped with a black bar on the bottom-right corner. This issue is reproducible in Safe Mode and with a brand-new admin user account. No third-party display or window management software installed. Suspected WindowServer display coordinate calculation bug within user session. Environment Device: MacBook Air M5 OS: macOS 27.2 RC (26B118) Display: Built-in display only, no external monitor Reproduction steps Boot to login window, display works fine Log into desktop session Display canvas cropped, black bar appears at bottom-right
Replies
1
Boosts
0
Views
1k
Activity
2w
M5 Pro external display pipeline width limits and native HiDPI support
Hello Apple Engineering Team, I would like to clarify a technical question regarding the external display architecture of the M5 Pro MacBook Pro. I use a single ultrawide monitor with a native resolution of 3440 × 1440. To achieve true 2× HiDPI rendering at this logical resolution, macOS would need to render a framebuffer of 6880 × 2880. Third-party diagnostic tools and firmware reverse-engineering reports appear to indicate that M5 Pro has display-pipeline source-width limits of 6720 and 7680 pixels. Could you please clarify the following? Are these reported source-width limits accurate for the M5 Pro? Can macOS assign a single external display to the display pipeline that supports a 7680-pixel source width? Is there a supported way to influence or change this pipeline allocation, such as changing the connection port, connection order, or display configuration? Can a single 3440 × 1440 external monitor use native 2× HiDPI rendering (6880 × 2880) on the M5 Pro without virtual-display mirroring? If this configuration is unsupported, is the limitation imposed by hardware, firmware, or macOS display allocation policy? I understand that Apple may not disclose all internal implementation details. Any clarification regarding supported configurations or known limitations would be greatly appreciated. Thank you.
Replies
0
Boosts
0
Views
501
Activity
2w
Public API for system-wide SDR luminance control on built-in XDR?
I am investigating whether a macOS display utility can adjust the luminance of normal SDR desktop content system-wide, including other apps, on the built-in Liquid Retina XDR display of a 2021 M1 Max MacBook Pro. Is there a documented public API, or combination of public APIs, for this scope? The research target is SDR white around 1000 cd/m² while retaining HDR highlight capability, where supported by the hardware and OS. This is a feasibility question, not a claim that this output has been achieved or is supported. The approach must preserve OS color management and respect thermal, power and brightness limits, including protective dimming. I am not seeking gamma-table changes, screen capture and HDR re-display, private APIs, or bypasses of system protections. I understand that enabling EDR for an app's own layer is different from controlling ordinary SDR content in other apps. I am specifically asking about the latter. If this is supported, could you point to the API names, primary documentation, applicable macOS versions and hardware limitations? If it is not supported through public APIs, an explicit clarification would also be helpful.
Replies
2
Boosts
0
Views
1.4k
Activity
3w
ScreenCaptureKit is NOT a full replacement for CGWindowListCreateImage
My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } which returns [CGWindowID] of all the Desktop background/wallpaper windows. Then for any one, say cgID, a simple let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgID, [.bestResolution]) gave an CGImage which then can be applied to my custom NSWindow. No where is TCC triggered. All is great. I followed Apple's ideas about Security and Privacy since I'm only using the data I need (i.e. [CGWindowID]) and the data is only used during execution. Never saved or shared. macOS 27 beta 4 and beyond broke CGWindowListCreateImage(...). It compiles and when called it returns some gray image. Documentation tells me to use ScreenCaptureKit. The newest versions of ScreenCaptureKit introduce SCScreenshotManager.captureImage(contentFilter:, configuration) which can return a CGImage of the CGWindowID. Here is when the problem occurs. To capture that CGWindowID CGImage, one would use SCContentFilter(desktopIndependentWindow: desktopWindow) but to get desktopWindow you first need to find the SCWindow that corresponds to CGWindowID. You can grab a set of SCWindow with SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: false) But when any method of SCShareableContent is called, TCC throws up this warning I do not want this. Too many permissions are being granted. I only want the [CGWindowID] of the Desktop background/wallpaper. This, if the user grants, gives me much more which is bad for Security and Privacy. One way to avoid the TCC in ScreenCaptureKit is to use the new SCContentSharingPicker.shared. This allows the user to pick what they want to share. I first tried var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.multipleWindows, .singleWindow] but the picker does not allow the user to select the Desktop background/wallpaper. Using var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.singleDisplay] also doesn't give me Desktop background/wallpaper access. Trying to use [.singleApplication] and limiting the choices to WindowServer (what SCWindow claims is the owner) also doesn't allow picking of the Desktop background/wallpaper. So, is it true to get access to the Desktop background/wallpaper CGWindowID's CGImage, I must have the user give me full access via TCC? Please tell me of a work around. The obvious fix is on Apple's side. The corresponding list of [SCWindow] corresponding to [CGWindowID] should always be included in SCContentFilter.includedWindows. Or simply leave them out of the TCC domain as before.
Replies
2
Boosts
0
Views
603
Activity
4w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
Replies
6
Boosts
2
Views
2.7k
Activity
Sep ’26
Game
In duo because of this design, most games like Call of Duty or Minecraft didn’t support this
Replies
0
Boosts
0
Views
705
Activity
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
Replies
3
Boosts
1
Views
1.9k
Activity
Sep ’26
Times New Roman superscript and Unicode fallback font
I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.
Replies
5
Boosts
0
Views
1.4k
Activity
Sep ’26
Efootball mobile
Tengo un iphone 13, estoy con ios 27 ultima beta reciente y juego efootball mobile pero anda horrible. Anda muy pesado.
Replies
0
Boosts
0
Views
1.1k
Activity
Sep ’26
Core Animation Background Thread CATransaction
Hey everyone 👋 I'm trying to initialize a part of a CALayer hierarchy on a background thread and then attach the root of that hierarchy to a CALayer that backs a UIView. The motivation is to keep the main thread responsive when constructing a complex layer hierarchy. This isn't a case where I'm creating two or three layers and then switching back to the main thread. The hierarchy can potentially contain a large number of layers, with animations being created/configured for those layers as well. My first approach was to create and configure the layers entirely on a background thread. While the output might be the expected one (not always), CoreAnimation emits an assertion along the lines of: "Modifications to the layer tree from a background thread may not be committed" (or something like this). This makes sense to me if implicit CATransaction is thread-local. In that case, the implicit transaction opened by the layer modification on the background thread would not be part of the transaction that is already open on the main thread. Therefore, committing the main-thread transaction would not commit the changes made on the background thread. My second approach was to explicitly create and commit a CATransaction on the background thread. This appears to be accepted by Core Animation's threading model, but I'm seeing unreliable results. Sometimes parts of the hierarchy are missing, and in other cases the hierarchy is present but the animations don't appear to run at all. I do understand that this is private behavior of the framework, but I wanted to know if what I am trying to achieve is possible and, if so, what the solution would be (obviously if you can share this information). Besides this, I would also like to know what behavior CATransactions have when they are created on different threads. What I mean by this is that the transactions work as a stack, and the changes are committed when the stack is empty. Does this behavior still apply when having transactions on different threads? Any weird behaviours that might appear between transactions operated on main vs background threads? Thank you! Vlad.
Replies
7
Boosts
0
Views
1.2k
Activity
Sep ’26