It doesn't give any build errors. I did not change any code as well for long. What do I do to fix the crash in runtime on iOS 14 with XCode 14 (older XCode did not give any issues as well with the same code)?

Someone needs to raise a request with DTS, but I am not sure even that would help.

No respite so far

Oops, a new crash happens when I handle the notification and reconfigure engine connections --" required condition is false: IsFormatSampleRateAndChannelCountValid(hwFormat)"

The crash is seen by the users despite handling this notification and reconfiguring the connections, though the crash now points to the line where I query inputNode outputformat. Will post the crash log in a reply to this post.

Thanks for the response. This notification is new information for me. So I just re-execute the last two lines of the code I posted while handling this notification? Do I need to stop the engine while doing so? What are the best practices for handling it?

This crash has been seen on 36 devices for an app that has 2500 downloads or so in the last 2 weeks or so (number of active users per day only around 100). And this number (36 devices) is from XCode crashes history, where I suppose it is comes from opt-in users only. Actual number of devices would be much more I suppose than this.

@eskimo I am not sure what happened, but I tried attaching it in full using the text attachment. Let me retry.

No, I didn't. I was not aware of mergeAttributes API, this is the first time I am working on a text editor that requires so many details. Also, I would need to resolve conflicts if they arise while merging attributes. That might require tracking existing attributes for subranges of text. Not sure if I am on the right path for the same.

No I don't use a custom cell, the standard cell with detailText. You are right, very hard to access UILabels or customize their properties.

But I still need to set the bounds of contentView to match the contentSize of UIScrollView. That is done by autolayout which is giving troubles. Not sure if manually setting the frame of contentview and disabling autolayout will solve the issue, but if it does, isn't it a bug in autolayout?

Thank you for responding, and that brings us to the original question -- on what extent rect is CIKernel processing done (it can't be infinite). How do I know the limits of destination coordinates in the kernel? I only get normalised texture coordinates in the kernel for the current pixel in processing. But just like Metal compute kernel if I need absolute coordinates I am currently computing, how do I get it? Simple example being if I need to put a 10 pixel red border around the border of input image, I don't see a straight forward way for the same.

Multiplying by alpha of inputImage worked, thanks. But I would really like to understand if one really needs to do the same multiply by alpha in every filter in the filter chain?

Thanks for the answer. Unfortunately, cropping to extent did not solve the problem. I found the real problem is another filter in filter chain that does a source over compositing, with compositing being done with a background image that is larger in size. The red pixels are filling the extent of that background image. No idea why the redKernel is being called for every pixel on the screen.

I have filed bug report FB9877123 . Waiting to hear from Apple Engineers.