Summary On iOS 18 and later, Chinese text rendering shows a noticeable performance regression related to the HVF (Hierarchical Variable Font) pipeline. Environment iOS Version: iOS 18+ Framework: libhvf.dylib (Hierarchical Variable Font) Affected Font: PingFangUI.ttc (private system font, automatically used for Chinese text) Related Frameworks: CoreText, CoreGraphics, FontParser Devices: All iOS devices (more noticeable on older hardware) Background iOS 18 Change: PingFang.ttc was removed from /System/Library/Fonts/ Private PingFangUI.ttc was added (inaccessible via normal font APIs) System automatically uses PingFangUI.ttc for all Chinese text rendering PingFangUI.ttc contains HVF tables → utilizes libhvf.dylib HVF Architecture: HVF (Hierarchical Variable Font) organizes glyphs as tree structures Each glyph = Composite → multiple Parts → nested hierarchy Rendering a single character requires traversing this tree Key Observation A single Chinese glyph typically triggers ~20 calls to HVF::LoaderHVGL::loadPartAtIndex. Cache invalidation is triggered via IncrementRenderCount after every 18 glyphs: __ZNK27THierVariationsDataForkFont20IncrementRenderCountEv: ldr w8, [x0, #0x12c] add w8, w8, #0x1 str w8, [x0, #0x12c] cmp w8, #0x12 b.lo return ldr x0, [x0, #0x120] bl HVF_clear_part_cache str wzr, [x19, #0x12c] return: ret This causes the cache to be cleared before a typical sentence finishes rendering. Complete Call Stack (Rendering Hot Path) #0-1 HVF::LoaderHVGL::loadPartAtIndex #2 HVF::FlatPartCache::partAtIndex #3 HVF::PartTransformRenderer::renderComposite #4 HVF::PartTransformRenderer::render #5 HVF::PartTransformRenderer::renderToContext #6 _HVF_render_current_part #7 THierVariationsFontHandler::GetOutlinePath #8 TFontHandler::CopyGlyphPath #9 THierVariationsFontHandler::CopyGlyphPath #10 TFPFont::CopyGlyphPath #11-12 TFPFont::CopyGlyphPath / _FPFontCopyGlyphPath #13 _CGFontCreateGlyphPath #14 _CGGlyphBuilderLockBitmaps #15 _render_glyphs #16 _draw_glyph_bitmaps #17 _ripc_DrawGlyphs #18 CG::DisplayList::executeEntries #19 _CGDisplayListDrawInContextDelegate #20 _CABackingStoreUpdate_ #21-22 CALayer display/layout #23-24 CA::Transaction::commit #25-30 UIApplicationMain / RunLoop HVF::LoaderHVGL::loadPartAtIndex is consistently observed as a hot function in Instruments and in production. Cache Clear Call Stack #0 HVF::FlatPartCache::clear #1 HVF_clear_part_cache #2 THierVariationsDataForkFont::IncrementRenderCount #3 THierVariationsFontHandler::GetOutlinePath #4 TFontHandler::CopyGlyphPath #5 FPFontCopyGlyphPath #6 CGFontCreateGlyphPath #7 _render_glyphs #8 _draw_glyph_bitmaps #9 _ripc_DrawGlyphs This shows that cache clearing occurs within the glyph rendering path. Impact For a typical Chinese sentence (~20 characters): Each glyph requires multiple part loads (~20 per glyph) Cache is cleared before rendering completes Previously loaded parts cannot be reused Observed effects: Increased loadPartAtIndex invocation count Low cache hit rate Increased CPU usage in glyph rendering Main-thread blocking during Core Animation commit Regression iOS 17 and earlier: Rendering is smooth under similar workloads. iOS 18+: Increased rendering cost and visible frame drops. The issue is more pronounced on older devices such as iPhone XS and iPhone 11. Reproduction Render a Chinese text string longer than 18 characters, for example: 刷新测试中文文本用于验证渲染性能问题需要超过十八个字 Observe: Repeated loadPartAtIndex calls Frequent cache clearing Request It would be helpful to review the cache eviction strategy for HVF, particularly for complex scripts such as Chinese. Potential considerations: Adjusting or scaling the cache threshold Avoiding full cache clears during continuous rendering Improving reuse of parts across glyphs within the same rendering batch

Our application is trying to read all resolutions of an external monitor. We have observed that, for the external monitor there is a mismatch in resolution list in our application and the resolution list in system settings. We are using the apple API "CGDisplayCopyAllDisplayModes" to read the resolutions.

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)

This crash has been troubling us for a long time. We have this crash report in every release of our App, but can't reproduce it. Here is part of the crash info: Incident Identifier: xxxx Hardware Model: iPhone13,3 Process: MyApp [34550] Path: /private/var/containers/Bundle/Application/xxxx/MyApp.app/MyApp Identifier: xxx.xxx Version: xxx (296) AppStoreTools: 15F31c AppVariant: 1:iPhone13,3:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: xxx.xxx [466] Date/Time: 2024-05-19 13:59:10.9716 +0800 Launch Time: 2024-05-19 12:18:24.8753 +0800 OS Version: iPhone OS 16.6.1 (20G81) Release Type: User Baseband Version: 3.80.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x322e323400000000 -> 0x0000003400000000 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x322e323400000000 VM Region Info: 0x3400000000 is in 0x1000000000-0x7000000000; bytes after start: 154618822656 bytes before end: 257698037759 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL ...(unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) UNUSED SPACE AT END Triggered by Thread: 0 Thread 0 name: Thread 0 Crashed: 0 CoreGraphics 0x00000001bd1d0780 CGFontStrikeRelease + 76 (CGFontStrike.c:126) 1 CoreGraphics 0x00000001bd1dd0cc CGGlyphBuilderUnlockBitmaps + 476 (CGGlyphBuilder.cc:113) 2 CoreGraphics 0x00000001bd1eb8c8 render_glyphs + 412 (RIPContextDrawGlyphs.c:127) 3 CoreGraphics 0x00000001bd202ea4 draw_glyph_bitmaps + 1132 (RIPContextDrawGlyphs.c:210) 4 CoreGraphics 0x00000001bd21a0ec ripc_DrawGlyphs + 1320 (RIPContextDrawGlyphs.c:558) 5 CoreGraphics 0x00000001bd1d26d8 CG::DisplayList::executeEntries(std::__1::__wrap_iter<std::__1::unique_ptr<CG::DisplayListEntry const, std::__1::default_delete<CG::DisplayListEntry const> >*>, std::__1::__wrap_iter<std::__1::uniq... + 5852 (DisplayList.cpp:1657) 6 CoreGraphics 0x00000001bd1c86a8 CGDisplayListDrawInContextDelegate + 268 (DisplayList.cpp:2151) 7 QuartzCore 0x00000001bcc797d4 CABackingStoreUpdate_ + 468 (CABackingStore.cpp:1388) 8 QuartzCore 0x00000001bccf0c34 invocation function for block in CA::Layer::display_() + 64 (CALayer.mm:9699) 9 QuartzCore 0x00000001bcc78d54 -[CALayer _display] + 1720 (CALayer.mm:9732) 10 QuartzCore 0x00000001bcc785b4 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 412 (CALayer.mm:2521) 11 QuartzCore 0x00000001bcc898d8 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 444 (CAContextInternal.mm:2714) 12 QuartzCore 0x00000001bccb8e80 CA::Transaction::commit() + 648 (CATransactionInternal.mm:432) 13 QuartzCore 0x00000001bcca2df0 CA::Transaction::flush_as_runloop_observer(bool) + 88 (CATransactionInternal.mm:940) 14 UIKitCore 0x00000001bdca34d0 _UIApplicationFlushCATransaction + 52 (UIApplication.m:3286) 15 UIKitCore 0x00000001bddf3d94 _UIUpdateSequenceRun + 84 (_UIUpdateSequence.mm:114) 16 UIKitCore 0x00000001be458894 schedulerStepScheduledMainSection + 144 (_UIUpdateScheduler.m:1015) 17 UIKitCore 0x00000001be457df0 runloopSourceCallback + 92 (_UIUpdateScheduler.m:1164) 18 CoreFoundation 0x00000001bb80a128 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1957) 19 CoreFoundation 0x00000001bb8167b4 __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2001) 20 CoreFoundation 0x00000001bb79b5e8 __CFRunLoopDoSources0 + 244 (CFRunLoop.c:2038) 21 CoreFoundation 0x00000001bb7b10d4 __CFRunLoopRun + 828 (CFRunLoop.c:2953) 22 CoreFoundation 0x00000001bb7b63ec CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418) 23 GraphicsServices 0x00000001f6ccc35c GSEventRunModal + 164 (GSEvent.c:2196) 24 UIKitCore 0x00000001bdb42f58 -[UIApplication _run] + 888 (UIApplication.m:3782) 25 UIKitCore 0x00000001bdb42bbc UIApplicationMain + 340 (UIApplication.m:5372) 26 MyApp 0x000000010468f978 main + 80 (main.m:15) 27 dyld 0x00000001dace8dec start + 2220 (dyldMain.cpp:1165) Thread 1 name: Thread 1: 0 libsystem_kernel.dylib 0x00000001fa6f6ca4 mach_msg2_trap + 8 (:-1) 1 libsystem_kernel.dylib 0x00000001fa709b74 mach_msg2_internal + 80 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00000001fa709e4c mach_msg_overwrite + 540 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00000001fa6f71e8 mach_msg + 24 (mach_msg.c:323) 4 CoreFoundation 0x00000001bb7b0024 __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2622) 5 CoreFoundation 0x00000001bb7b1250 __CFRunLoopRun + 1208 (CFRunLoop.c:3005) 6 CoreFoundation 0x00000001bb7b63ec CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418) 7 Foundation 0x00000001b5a2efb4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 (NSRunLoop.m:373) 8 Foundation 0x00000001b5a2ee9c -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 (NSRunLoop.m:420) 9 UIKitCore 0x00000001bdc75cc8 -[UIEventFetcher threadMain] + 416 (UIEventFetcher.m:1376) 10 Foundation 0x00000001b5a48524 __NSThread__start__ + 716 (NSThread.m:963) 11 libsystem_pthread.dylib 0x000000021b5766b8 _pthread_start + 148 (pthread.c:893) 12 libsystem_pthread.dylib 0x000000021b575b88 thread_start + 8 (:-1) Thread 2: 0 libsystem_kernel.dylib 0x00000001fa6f7164 __semwait_signal + 8 (:-1) 1 libsystem_c.dylib 0x00000001c2c50888 nanosleep + 220 (nanosleep.c:104) 2 libsystem_c.dylib 0x00000001c2c61b1c sleep + 52 (sleep.c:62) 3 MyApp 0x00000001075ccb14 -[UTDCacheManager synchronizeData] + 104 (UTDCacheManager.m:133) 4 Foundation 0x00000001b5a48524 __NSThread__start__ + 716 (NSThread.m:963) 5 libsystem_pthread.dylib 0x000000021b5766b8 _pthread_start + 148 (pthread.c:893) 6 libsystem_pthread.dylib 0x000000021b575b88 thread_start + 8 (:-1)

I am a professional user of the 2019 Mac Pro (7,1) with dual AMD Radeon Pro W6900X MPX modules (32GB VRAM each). This hardware is designed for high-performance compute, but it is currently crippled for modern local LLM/AI workloads under Linux due to Apple's EFI/PCIe routing restrictions. Core Issue: rocminfo reports "No HIP GPUs available" when attempting to use ROCm/amdgpu on Linux Apple's custom EFI firmware blocks full initialization of professional GPU compute assets The dual W6900X GPUs have 64GB combined VRAM and high-bandwidth Infinity Fabric Link, but cannot be fully utilized for local AI inference/training My Specific Request: Apple should provide an official, one-click deployable application that enables full utilization of dual W6900X GPUs for local large language model (LLM) inference and training under Linux. This application must: Fully initialize both W6900X GPUs via HIP/ROCm, establishing valid compute contexts Bypass artificial EFI/PCIe routing restrictions that block access to professional GPU resources Provide a stable, user-friendly one-click deployment experience (similar to NVIDIA's AI Enterprise or AMD's ROCm Hub) Why This Matters: The 2019 Mac Pro is Apple's flagship professional workstation, marketed for compute-intensive workloads. Its high-cost W6900X GPUs should not be locked down for modern AI/LLM use cases. An official one-click deployment solution would demonstrate Apple's commitment to professional AI and unlock significant value for professional users. I look forward to Apple's response and a clear roadmap for enabling this critical capability. #MacPro #Linux #ROCm #LocalLLM #W6900X #CoreML

For an app of mine I use CGSetDisplayTransferByTable to adjust the gamma table of the device. Since macOS Tahoe, these modifications are silently ignored. The display's actual gamma curve remains unchanged despite the API reporting successful completion. I've filed a FB for it a few weeks ago, and would love to figure out what could be causing this. FB18559786

I am working on a remote control application for macOS where I need to maintain two "virtual" cursors: Remote Cursor: Follows the remote user's movements. Local Cursor: Follows the local user's physical mouse/trackpad movements. To move the system cursor (for the remote side), I use CGWarpMouseCursorPosition as follows: void DualCursorMac::UpdateSystemCursorPosition(int x, int y) { CGPoint point = CGPointMake(static_cast<CGFloat>(x), static_cast<CGFloat>(y)); // Warp the cursor to match remote coordinates CGWarpMouseCursorPosition(point); } Meanwhile, I use a CGEventTap to monitor local physical movements to update my local virtual cursor's UI: CGEventRef Mouse::MouseTapCallback(CGEventTapProxy proxy, CGEventType type, CGEventRef event, void *refcon) { if (remoteControlMode) { // We want to suppress system cursor movement but still read the delta const int deltaX = static_cast<int>(CGEventGetIntegerValueField(event, kCGMouseEventDeltaX)); const int deltaY = static_cast<int>(CGEventGetIntegerValueField(event, kCGMouseEventDeltaY)); NSLog(@"MouseTapCallback: delta:(%d, %d)", deltaX, deltaY); // Update local virtual cursor UI based on deltas... return nullptr; // Consume the event } return event; } The Problem: When CGWarpMouseCursorPosition is called frequently to update the system cursor, it interferes with the kCGMouseEventDeltaX/Y values in the Event Tap. Specifically, if the local user moves the trackpad slowly (expecting deltas of 1 or 2), but a "Warp" occurs simultaneously (e.g., jumping the cursor from (100, 100) to (300, 300)), the deltaX and deltaY in the callback suddenly spike to very large values. It seems the system calculates the delta based on the new warped position rather than the pure physical displacement of the trackpad. This makes the local virtual cursor "jump" erratically and makes it impossible to track smooth local movement during remote control. My Question: Is there a way to get the "raw" or "pure" physical relative movement (delta) from the trackpad/mouse that is independent of the system cursor's absolute position or warping? Are there alternative APIs (perhaps IOKit or different CGEvent fields) that would allow me to get consistent deltas even when the cursor is being warped programmatically?

Hi! I hope everyone reading is doing well. I am working on developing a reinforcement learning agent that involves sending scan codes to a window, which I've been doing by sending virtual scan codes with CGEventCreateKeyboardEvent per the docs. There is no event source when I send the keyboard events. However, when many keyboard events are happening (with the keys 'q', 'w', 'e', 'r', 'f', 'd', 's', space, arrow keys) in quick succession (<250ms), the enable dictation popup or the function button emojis popup appear for seemingly no reason. I have verified that I am using the correct scan codes for these keypresses, so I am wondering what else could cause this to happen. It is as if I am choosing to press f5 or fn. It does not happen when 'a' is the only button being pressed in quick succession. One thing that I have not been able to easily find is the scan code inputs for dictation nor the function button. do these scan codes overlap somehow? Thank you all for the help! Hunter

I have a MacOS app which displays PDFs, and I want to create a New document from the Clipboard, if the clipboard contains valid graphical data. My problem is that even if it doesn't, I still get a blank new document window. AppKit always creates a new document. I've tried overriding the newDocument function; I've tried avoiding the built-in functions altogether. Are there any general recommendations for going about this?

With iOS 26.1 we started seeing a bug that only appears on iPhone Air. This bug is visible with simulators too. I have tried so many different ways to fix the issue, but Instruments Profiler is pointing at UIKitCore. We load a tab bar, when the user attempts to switch a tab, the app hangs and never recovers. It happens right as the animation of the Glass bubble is in progress. I have tried a UIKit Tab bar, a SwiftUI Tab bar. I tore out AppDelegate and did a direct @main SwiftUI entry for my application. This issue appears with every tab bar instance I try. I attempted to disable LiquidGlass by utilizing this flag UIDesignRequiresCompatibility in my plist, but the flag seems to be ignored by the system. I am not sure what else to try. I have a trace file if that is helpful. What else can I upload? Here is what the code looks like. struct ContentView: View { @State private var selectedTab = 2 var body: some View { TabView(selection: $selectedTab) { Text("Profile") .tabItem { Label("Me", systemImage: "person") } .tag(0) Text("Training") .tabItem { Label("Training", systemImage: "calendar") } .tag(1) Text("Home") .tabItem { Label("Home", systemImage: "house") } .tag(2) Text("Goals") .tabItem { Label("Goals", systemImage: "target") } .tag(3) Text("Coach") .tabItem { Label("Coach", systemImage: "person.2") } .tag(4) } } } #Preview { ContentView() } and AppView entry point import SwiftUI @main struct RunCoachApp: App { var body: some Scene { WindowGroup { ContentView() } } }

We used below method to resize image while compress the image, Below method is correct or need to do the correction in method or "CGBitmapContextCreate" -(UIImage *)resizeImage:(UIImage *)anImage width:(int)width height:(int)height { CGImageRef imageRef = [anImage CGImage]; CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(imageRef); if (alphaInfo == kCGImageAlphaNone) alphaInfo = kCGImageAlphaNoneSkipLast; CGContextRef bitmap = CGBitmapContextCreate(NULL, width, height, CGImageGetBitsPerComponent(imageRef), 4 * width, CGImageGetColorSpace(imageRef), alphaInfo); CGContextDrawImage(bitmap, CGRectMake(0, 0, width, height), imageRef); CGImageRef ref = CGBitmapContextCreateImage(bitmap); UIImage *result = [UIImage imageWithCGImage:ref]; CGContextRelease(bitmap); CGImageRelease(ref); return result; }

The Test target not build for not such file or directory: 'CoreGraphics'. Not sure why I get this error, but I configured the target without forgetting the variables BUNDLE_LOADER with $(BUILT_PRODUCTS_DIR)/MyExistingApp.app/MyExistingApp value and TEST_HOST with $(BUNDLE_LOADER) value. App target (not the test target), the Symbols Hidden by Default build setting its equal to NO, unlike the Test target that is set to YES. Any variable more for this? I'm not sure if I should take anything into account when using Xcode 26.1.1 and Swift Testing framework.

Same PDF renders differently when open in Chrome, Safari; Apple Preview, Acrobat. on Apple Preview, Safari - the PDF appears correctly for a second or two and then appears washed out. Our app uses Safari to render PDFs and our users are complaining that scanned PDFs are not rendering properly. How do I fix this issue (Swift, Obj-C)?

using renderInContext fetch pixel faild if subviews contains WKWebView, the code is as follows: self.contentView = [SimpleClearContentView alloc] initWithFrame:CGRectMake(0, 100, 100, 100)]; contentView.backgroundColor = [UIColor clearColor]; self.contentView.webView = [[WKWebView alloc] init]; self.contentView.webView.frame = CGRectMake(0, 0, 50, 100); // make web view clear bg color self.contentView.webView.backgroundColor = [UIColor clearColor]; self.contentView.webView.scrollView.backgroundColor = [UIColor clearColor]; // webView load clear background webpage [self.contentView.webView loadRequest:xxx]; [self.view addSubView:contentView]; // this method still return 0.0f anywhere -(CGFloat)getPixelAlphaAtPoint:(CGPoint)point { unsigned char pixel[4] = {0}; CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB(); CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, kCGBitmapAlphaInfoMask & kCGImageAlphaPremultipliedLast); CGContextTranslateCTM(context, -point.x, -point.y); WKWebView *webView = self.contentView.webView; [webView.layer renderInContext:context]; CGContextRelease(context); CGColorSpaceRelease(colorSpace); CGFloat alpha = pixel[3]/255.0; return alpha; }

How does one know the fitting width of a UIDatePicker in a selector hooked up with UIControlEventValueChanged? By fitting width, I mean the width of the grey background rounded box displayed with the date -- I need to get the width of that whenever the date is changed.

Steps to Reproduce: Connect a MacBook Pro (lid closed) to a large external monitor. Run the SDL3 testwm test application. git clone https://github.com/libsdl-org/SDL.git cmake -S . -B build -DBUILD_SHARED_LIBS=OFF -DSDL_TESTS=ON cmake --build build The testwm binary will be located in the build/test directory. Move the application window around the left edge of the external display. Observed Result: WindowServer crashes. System Configuration: MacBook Pro M3 Max, macOS Sequoia 15.6.1 LG GX9, 5120x2160 resolution, running at 165 Hz refresh rate Lid closed, single external display Panic Log: panic(cpu 7 caller 0xfffffe0027f61d5c): "mismatched swapID's 6386399 vs 6386400\n" @UnifiedPipeline.cpp:14570 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 24G90 Kernel version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:55 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6031 Fileset Kernelcache UUID: 8AA69CD2038CD2BAE2ED364428F4DBEA Kernel UUID: 75A21406-D046-3232-AA3F-085335D5C848 Boot session UUID: B949E839-683B-4DAF-BE42-4562758F976E iBoot version: iBoot-11881.140.96 iBoot Stage 2 version: iBoot-11881.140.96 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x000000001e0ec000 KernelCache base: 0xfffffe00250f0000 Kernel slide: 0x000000001e0f4000 Kernel text base: 0xfffffe00250f8000 Kernel text exec slide: 0x000000001f870000 Kernel text exec base: 0xfffffe0026874000 mach_absolute_time: 0x64e7db3e6a9 Epoch Time: sec usec Boot : 0x68b207f0 0x00082ee7 Sleep : 0x68c1a51c 0x00048c6c Wake : 0x68c1a760 0x00039aa4 Calendar: 0x68c1b78d 0x0001776a Zone info: Zone map: 0xfffffe1018000000 - 0xfffffe3618000000 . VM : 0xfffffe1018000000 - 0xfffffe15e4000000 . RO : 0xfffffe15e4000000 - 0xfffffe187e000000 . GEN0 : 0xfffffe187e000000 - 0xfffffe1e4a000000 . GEN1 : 0xfffffe1e4a000000 - 0xfffffe2416000000 . GEN2 : 0xfffffe2416000000 - 0xfffffe29e2000000 . GEN3 : 0xfffffe29e2000000 - 0xfffffe2fae000000 . DATA : 0xfffffe2fae000000 - 0xfffffe3618000000 Metadata: 0xfffffe393c010000 - 0xfffffe3945810000 Bitmaps : 0xfffffe3945810000 - 0xfffffe394c104000 Extra : 0 - 0 CORE 0 recently retired instr at 0xfffffe0026a407a0 CORE 1 recently retired instr at 0xfffffe0026a40798 CORE 2 recently retired instr at 0xfffffe0026a407a0 CORE 3 recently retired instr at 0xfffffe0026a407a0 CORE 4 recently retired instr at 0xfffffe0026a407a0 CORE 5 recently retired instr at 0xfffffe0026a407a0 CORE 6 recently retired instr at 0xfffffe0026a407a0 CORE 7 recently retired instr at 0xfffffe0026a3eefc CORE 8 recently retired instr at 0xfffffe0026a407a0 CORE 9 recently retired instr at 0xfffffe0026a407a0 CORE 10 recently retired instr at 0xfffffe0026a407a0 CORE 11 recently retired instr at 0xfffffe0026a407a0 CORE 12 recently retired instr at 0xfffffe0026a407a0 CORE 13 recently retired instr at 0xfffffe0026a407a0 TPIDRx_ELy = {1: 0xfffffe29e4ef5ee0 0: 0x0000000000001007 0ro: 0x000000016c59b0e0 } CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 8 PVH locks held: None CORE 9 PVH locks held: None CORE 10 PVH locks held: None CORE 11 PVH locks held: None CORE 12 PVH locks held: None CORE 13 PVH locks held: None CORE 0: PC=0xfffffe0026abfa40, LR=0xfffffe0026ae4fc8, FP=0xfffffe65b8703980 CORE 1: PC=0x0000000193ae2730, LR=0x000000019389d108, FP=0x000000016f43e590 CORE 2: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b850bed0 CORE 3: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b8ee7ed0 CORE 4: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b7eebed0 CORE 5: PC=0xfffffe0026a3ac1c, LR=0xfffffe0026a3ac18, FP=0xfffffe65b8c63e40 CORE 6: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b7033ed0 CORE 7 is the one that panicked. Check the full backtrace for details. CORE 8: PC=0xfffffe0026a3ac1c, LR=0xfffffe0026a3ac18, FP=0xfffffe65b737be40 CORE 9: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b8f1fed0 CORE 10: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b7fe7ed0 CORE 11: PC=0xfffffe0026a3ac1c, LR=0xfffffe0026a3ac18, FP=0xfffffe65b870fe40 CORE 12: PC=0xfffffe0026911e84, LR=0xfffffe0026911e84, FP=0xfffffe65b80a7ed0 CORE 13: PC=0xfffffe0026a3ac1c, LR=0xfffffe0026a3ac18, FP=0xfffffe65b685fe40 Compressor Info: 6% of compressed pages limit (OK) and 16% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe23153cb940: 10375 pages, 28 threads: pid 406: WindowServer Panicked thread: 0xfffffe29e4ef5ee0, backtrace: 0xfffffe65b6f07210, tid: 5146 lr: 0xfffffe00268d53d4 fp: 0xfffffe65b6f072a0 lr: 0xfffffe0026a36da0 fp: 0xfffffe65b6f07310 lr: 0xfffffe0026a35114 fp: 0xfffffe65b6f073d0 lr: 0xfffffe002687f8b0 fp: 0xfffffe65b6f073e0 lr: 0xfffffe00268d5710 fp: 0xfffffe65b6f077b0 lr: 0xfffffe0027169290 fp: 0xfffffe65b6f077d0 lr: 0xfffffe0027f61d5c fp: 0xfffffe65b6f07850 lr: 0xfffffe0029186878 fp: 0xfffffe65b6f07880 lr: 0xfffffe00270bd2a0 fp: 0xfffffe65b6f078b0 lr: 0xfffffe00270bd5b0 fp: 0xfffffe65b6f07a40 lr: 0xfffffe0026a00194 fp: 0xfffffe65b6f07b60 lr: 0xfffffe00268dcd48 fp: 0xfffffe65b6f07c00 lr: 0xfffffe00268b2ed4 fp: 0xfffffe65b6f07c60 lr: 0xfffffe00268c6868 fp: 0xfffffe65b6f07cb0 lr: 0xfffffe00268c6c80 fp: 0xfffffe65b6f07da0 lr: 0xfffffe0026a29bbc fp: 0xfffffe65b6f07e50 lr: 0xfffffe0026a355a4 fp: 0xfffffe65b6f07f10 lr: 0xfffffe002687f8b0 fp: 0xfffffe65b6f07f20 lr: 0x000000018dc89c34 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.iokit.IOMobileGraphicsFamily(343.0)[6C8CFA29-99CD-39D4-81BC-2B0F147BE64F]@0xfffffe002917d860->0xfffffe00291a024f

I have a PDF which contains geocoordinates. I'm extracting out that image with the following code (this is for an iOS application): guard let cgDocument = CGPDFDocument(overlay.pdfUrl as CFURL) else { return } guard let cgPage = cgDocument.page(at: 1) else { return } var boundingRect = self.rect(for: overlay.boundingMapRect) let pdfPageRect = cgPage.getBoxRect(.mediaBox) let renderer = UIGraphicsImageRenderer(size: pdfPageRect.size) var img = renderer.image { ctx in UIColor.white.set() ctx.fill(pdfPageRect) ctx.cgContext.translateBy(x: 0.0, y: pdfPageRect.size.height) ctx.cgContext.scaleBy(x: 1.0, y: -1.0) ctx.cgContext.drawPDFPage(cgPage) } Once I have that image, I then need to adjust it to fit the specific coordinate corners. For that, I'm doing the following using a perspectiveTransform: let ciImg = CIImage(image: img)! let perspectiveTransformFilter = CIFilter.perspectiveTransform() perspectiveTransformFilter.inputImage = ciImg perspectiveTransformFilter.topRight = cartesianForPoint(point: ur, extent: boundingRect) perspectiveTransformFilter.topLeft = cartesianForPoint(point: ul, extent: boundingRect) perspectiveTransformFilter.bottomRight = cartesianForPoint(point: lr, extent: boundingRect) perspectiveTransformFilter.bottomLeft = cartesianForPoint(point: ll, extent: boundingRect) let txImg = perspectiveTransformFilter.outputImage! img = UIImage(ciImage: txImg) The original image is 792 x 612 (a landscape PDF) but the boundingRect covering the coordinates is 25625 x 20030. Obviously when I try to draw the image into that bounding box the app runs out of memory (25625 x 20030 x 4 is around 2GB of memory). What I'm struggling with is - how do I correctly scale this image to fit into the bounding box even though the bounding box is, oh, 10x the resolution of the actual device? There's some key CoreGraphics thing I'm sure I'm missing here.

Hi, This can't be right. Is there really no replacement for Quartz Debug?!? As the sole developer on a project who has an Intel Mac and Quartz Debug, I am basically a god now. Everyone else has Apple Silicon and... I think they're randomly guessing at this point. Because I have entire teams sending me Intel Mac builds of stuff just so I can test it in QD. This is THE TOOL we used at NewTek to find performance issues, and THE TOOL I used for a dozen companies after that, to help them with similar issues. If there's no replacement, is there a reason there's no replacement? This feels like a massive step backwards, having to guess at problems like this. -Chilton

Some users reported that their images are not loading correctly in our app. After a lot of debugging we identified the following: This only happens when the app is build for Mac Catalyst. Not on iOS, iPadOS, or “real” macOS (AppKit). The images in question have unusual color spaces. We observed the issue for uRGB and eciRGB v2. Those images are rendered correctly in Photos and Preview on all platforms. When displaying the image inside of a UIImageView or in a SwiftUI Image, they render correctly. The issue only occurs when loading the image via Core Image. When comparing the different Core Image render graphs between AppKit (working) and Catalyst (faulty) builds, they look identical—except for the result. Mac (AppKit): Catalyst: Something seems to be off when Core Image tries to load an image with foreign color space in Catalyst. We identified a workaround: By using a CGImageDestination to transcode the image using the kCGImageDestinationOptimizeColorForSharing option, Image I/O will convert the image to sRGB (or similar) and Core Image is able to load the image correctly. However, one potentially loses fidelity this way. Or might there be a better workaround?

So I get JPEG data in my app. Previously I was using the higher level NSBitmapImageRep API and just feeding the JPEG data to it. But now I've noticed on Sonoma If I get a JPEG in the CMYK color space the NSBitmapImageRep renders mostly black and is corrupted. So I'm trying to drop down to the lower level APIs. Specifically I grab a CGImageRef and and trying to use the Accelerate API to convert it to another format (to hopefully workaround the issue... CGImageRef sourceCGImage = `CGImageCreateWithJPEGDataProvider(jpegDataProvider,` NULL, shouldInterpolate, kCGRenderingIntentDefault); Now I use vImageConverter_CreateWithCGImageFormat... with the following values for source and destination formats: Source format: (derived from sourceCGImage) bitsPerComponent = 8 bitsPerPixel = 32 colorSpace = (kCGColorSpaceICCBased; kCGColorSpaceModelCMYK; Generic CMYK Profile) bitmapInfo = kCGBitmapByteOrderDefault version = 0 decode = 0x000060000147f780 renderingIntent = kCGRenderingIntentDefault Destination format: bitsPerComponent = 8 bitsPerPixel = 24 colorSpace = (DeviceRBG) bitmapInfo = 8197 version = 0 decode = 0x0000000000000000 renderingIntent = kCGRenderingIntentDefault But vImageConverter_CreateWithCGImageFormat fails with kvImageInvalidImageFormat. Now if I change the destination format to use 32 bitsPerpixel and use alpha in the bitmap info the vImageConverter_CreateWithCGImageFormat does not return an error but I get a black image just like NSBitmapImageRep