@YuAo, I saw your kernel code. I don't understand why 0.5 offset has been added in both x and y coordinates when you compute `vec2 redCoord = samplerTransform(toneCurveTexture,vec2(textureColor.r * 255.0 + 0.5 + toneCurveTextureExtent.x, toneCurveTextureExtent.y + 0.5)); ?

I think in this case, CIContext may also need to be initialised with metalDevice, correct?

It will take time to prepare a minimally reproducible sample code, I shall definitely do that. But in any case I need a workaround or alternative way to detect seek has finished.

I see this problem is reproducible only when playerItem.seekingWaitsForVideoCompositionRendering = true is set. Otherwise I have not been able to reproduce it so far.

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

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.

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?

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.

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?

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.

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.

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

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.

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?

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.