Post

Replies

Boosts

Views

Activity

Reply to NSScreen frame location with multiple monitors
Here is what I see in System Information: USB-C Digital AV Multiport Adapter: Product ID: 0x1463 Vendor ID: 0x05ac (Apple Inc.) Version: 45.00 Serial Number: DLC3032047WKD56AR Speed: Up to 12 Mb/s Manufacturer: Apple Inc Location ID: 0x03120000 / 3 Current Available (mA): 500 Current Required (mA): 100 Extra Operating Current (mA): 0 USB-C Digital AV Multiport Adapter: Product ID: 0x1463 Vendor ID: 0x05ac (Apple Inc.) Version: 45.00 Serial Number: DLC2512012HKD56AS Speed: Up to 12 Mb/s Manufacturer: Apple Inc Location ID: 0x01120000 / 3 Current Available (mA): 500 Current Required (mA): 100 Extra Operating Current (mA): 0 USB-C Digital AV Multiport Adapter: Product ID: 0x1463 Vendor ID: 0x05ac (Apple Inc.) Version: 45.00 Serial Number: DLC303203HRKD56A1 Speed: Up to 12 Mb/s Manufacturer: Apple Inc Location ID: 0x02120000 / 3 Current Available (mA): 500 Current Required (mA): 100 Extra Operating Current (mA): 0 USB-C Digital AV Multiport Adapter: Product ID: 0x1463 Vendor ID: 0x05ac (Apple Inc.) Version: 45.00 Serial Number: DLC415301BYKD56A3 Speed: Up to 12 Mb/s Manufacturer: Apple Inc Location ID: 0x00120000 / 3 Current Available (mA): 500 Current Required (mA): 100 Extra Operating Current (mA): 0
Nov ’24
Reply to NSScreen frame location with multiple monitors
After several reboots, MacOS decided to play random monitors. The monitors are in a completely different order than before. Globals initializeScreens - screen 1 'PHL 346E2C' Globals initializeScreens - '<NSScreen: 0x600000dd0a20; name="PHL 346E2C"; backingScaleFactor=1.000000; frame={{0, 0}, {3440, 1440}}; visibleFrame={{0, 0}, {3440, 1415}}>' Globals initializeScreens - screen 2 'Blackmagic (2)' Globals initializeScreens - '<NSScreen: 0x600000dd0a80; name="Blackmagic (2)"; backingScaleFactor=1.000000; frame={{5360, 0}, {1920, 1080}}; visibleFrame={{5360, 0}, {1920, 1055}}>' Globals initializeScreens - screen 3 'Blackmagic (1)' Globals initializeScreens - '<NSScreen: 0x600000dd0b40; name="Blackmagic (1)"; backingScaleFactor=1.000000; frame={{-3840, 0}, {1920, 1080}}; visibleFrame={{-3840, 0}, {1920, 1055}}>' Globals initializeScreens - screen 4 'Blackmagic (4)' Globals initializeScreens - '<NSScreen: 0x600000dd0ba0; name="Blackmagic (4)"; backingScaleFactor=1.000000; frame={{-1920, 0}, {1920, 1080}}; visibleFrame={{-1920, 0}, {1920, 1055}}>' Globals initializeScreens - screen 5 'Blackmagic (3)' Globals initializeScreens - '<NSScreen: 0x600000dd0c00; name="Blackmagic (3)"; backingScaleFactor=1.000000; frame={{3440, 0}, {1920, 1080}}; visibleFrame={{3440, 0}, {1920, 1055}}>' Is there any way to use a configuration file to lock down these settings? Or maybe have the sequence be consistent? This is not good. How can folks that use multiple monitors for displays make this work?
Nov ’24
Reply to CIKernel call - performance hit and memory leak
I found a workaround. The CIImage that was queued for feedback had several Kernel filters applied to it. This seemed to be the cause of the memory issue. My workaround is to convert the CIImage to NSImage and then back to CIImage when adding it to the feedback queue. The CIImage from the NSImage has eliminated all of the intermediate operations that were in the original CIImage. This is not very elegant, but it works. The virtual memory size is rock solid.
Apr ’22
Reply to CIKernel call - performance hit and memory leak
If I simply 'return foreground!' or 'return background!' there is no memory issue. If I invoke the filter in the code below, the memory use rapidly increases and performance degrades. If left going long enough, it will use all virtual memory and crash.    private static func CISourceOverCompositing() -> CIImage?   {           return background!           let result = CIFilter(        name: "CISourceOverCompositing",        parameters: [         "inputImage": foreground!,         "inputBackgroundImage": background!        ])?       .outputImage!.cropped(to: extent!)           return result!   }
Apr ’22
Reply to CIKernel call - performance hit and memory leak
In addition to the memory issue, I've found a performance issue. In my original post, I passed three CIImage instances to the CIKernel. This caused a memory issue. I removed one of the CIImage instances for testing, and the memory issue went away. Next I found that the export processing speed continued to degrade. Exporting the first minute measured about 20 frames per second. Exporting the first two minutes degraded to about 9 frames per second. I stopped the third attempt after around five minutes. I did another comparison. Passing the input source image and a gradient image for a two minute test took was about 28 frames per second. But when I pass the input image and a feedback image, it degraded to about 9 frames per second for a two minute export. The difference is that the gradient CIImage is static throughout the processing. The feedback CIImage is a queued image delayed from ten frames previously. That's the only clue I have for the performance. The performance degrades quickly over time. It starts out relatively fast and quickly degrades. I'm open to more debugging but am at a loss of how to dig any deeper on this.
Apr ’22
Reply to CIKernel call - performance hit and memory leak
A little more detail about this. I am testing using a five-minute video 1920x1080. This filter receives a CIImage that has been queued from a previous frame. So the feedback image is different for each frame. I'm guessing that somehow a reference to the feedback image is being retained but I don't know how I can prove it. The memory usage is steadily increasing over time. The memory use gradually increases to more than 6 GB. I've save the .trace file, but unfortunately the forum won't allow me to post a link to DropBox. I've also tried changing the call in the Swift to use weak vars and pass them. It did not help.          // test                   weak var feedback2 = feedback         weak var gradient2 = gradient         weak var image2 = self.inputImage                   // performance issue arises when passing in the 'feedback' image!                   let result = ciKernel!.apply(extent: self.inputImage!.extent,                   roiCallback: { [self]          (index, rect) -> CGRect in            let roiRect = rect.insetBy(dx: -1 * range, dy: -1 * range )            return roiRect          },           arguments: [ image2!, gradient2!, feedback2!, time, threshold, scaledOption])         //       CIImage,      CIImage,  CIImage,  Float, Float,   Float         // FeedbackIn(coreimage::sampler src, coreimage::sampler gradient, coreimage::sampler feedback, float time, float threshold, float optionValue, coreimage::destination dest )
Apr ’22
Reply to Edit and play back HDR video with AVFoundation - WWDC20-10009 - Export dialog hangs at 100%
after a lot of trial and error, I was able to fix the problem. I added the line with the comment below.  exportProgressChecker = AssetExporter.exportAsynchronously(exportFileURL: dialog.url!) {         if self.exportProgressChecker != nil && self.exportProgressChecker!.succeeded {                      self.showingExportProgress = false     // adding this line fixed the issue.           self.triggerAlert(reason: .exportDone)
Mar ’22
Reply to Edit and play back HDR video with AVFoundation - WWDC20-10009 - Export dialog hangs at 100%
Ok I've made a little progress. In ContentView.swift, there is a section of code that is trying to display the "Export Finished" alert. But the "Export Progress" alert is still being displayed at 100%. I've put a comment in the code where I think there needs to be some statement to close the "Export Progress" popup. I have no idea of how to do that. alert(isPresented: $showingAlert) {         switch alertReason {         ... )         case .exportDone:            // need to close the previous alert for export progress!!!            return Alert(title: Text("Export finished"), message: nil, dismissButton: Alert.Button.default(Text("OK"), action: {             self.showingExportProgress = false           })) .sheet(isPresented: $showingExportProgress) {         ProgressPopup(isVisible: self.$showingExportProgress, title: Text("Exporting ..."), progressUpdateHandler: { () -> Float in           return self.exportProgressChecker?.progress ?? 0         })       } The ProgressPopup is a struct: struct ProgressPopup: View { ... Questions: Can I add a .close() function to the struct that would tell it to go away? What would it look like? The ProgressPopup is displayed with this statement: .sheet(isPresented: $showingExportProgress) {         ProgressPopup(isVisible: self.$showingExportProgress, title: Text("Exporting ..."), progressUpdateHandler: { () -> Float in           return self.exportProgressChecker?.progress ?? 0         })       } But there doesn't seem to be a variable that saves a reference to it anywhere, so even if I could make a close() function from question 1, I would still need to be able to invoke the new function to close the popup. Thanks to all for reading!
Mar ’22