Fix conditions where BackgroundReplacementProvider needs to be re-rendered, Fix to not log the entire options object

[ziyiz-amzn]

Issue #:

Description of changes:

1. Fix the conditions where BackgroundReplacementProvider needs to be re-rendered. Remove the image size comparison because now it supports dynamically change replacement image in an active processor. The processor recreation when image changes will cost to fetch assets again.
2. Avoid to log the entire options props in BackgroundReplacementProvider, the optional logger prop could potentially be nested JSON.

Testing

1. Have you successfully run npm run build:release locally?
   Yes

2. How did you test these changes?

3. Locally and private build tested by QA

4. If you made changes to the component library, have you provided corresponding documentation changes?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[xuesichao]

Do we need to keep the comparison for imageBlob?.size?

[xuesichao]

Remove the image size comparison because now it supports dynamically change replacement image in an active processor. The processor recreation when image changes will cost to fetch assets again.

There're two independent ways to update BGR:

1. dynamically change replacement image in an active processor via changeBackgroundReplacementImage from useBackgroundReplacement hook
2. update the options props of BackgroundReplacementProvider

Is it a breaking change that removing the comparison for imageBlob seems to affect the second flow?

[ziyiz-amzn]

I prefer to remove this comparison.

1. image in the constructor should only take effect when initiate the component, changing image should always through API processor.setImageBlob(imageBlob).
2. Also, I verified that assets will be re-fetched if BackgroundReplacementProvider re-renders, we may want to avoid it.

I will merge this PR only after QA's signoff.

[ziyiz-amzn]

Is it a breaking change that removing the comparison for imageBlob seems to affect the second flow?

Before this change, the provider will never be re-created even if pass in a different image in constructor. Thus, I don't think it's breaking. correct me if wrong.

[xuesichao]

1. image in the constructor should only take effect when initiate the component, changing image should always through API processor.setImageBlob(imageBlob).
2. Also, I verified that assets will be re-fetched if BackgroundReplacementProvider re-renders, we may want to avoid it.

I agree this is best practice. However before previous release, processor.setImageBlob was not available in React SDK. And builders can only rely on the options props change to re render entire BackgroundReplacementProvider to update the processor. Though there's a bug to make it never works, so this
change may not be a breaking one.

My thought is the behavior of BGB and BGR provider should align meaning any change of their configuration in the provider props should cause the provider to re-render.

• https://github.com/aws/amazon-chime-sdk-js/blob/main/guides/15_Background_Filter_Video_Processor.md#configuration

[michhyun1]

What use case is there for the BGBlur or BGR Provider to re-render? When would they need to kill the old processor and create a new one?

I think the preferred behavior is that the BGBlur and BGR provider just take in an initial props, but don't re-render on those prop changes.

Instead, we should just expose functions to dynamically change the processor with a new image blob, or new blur strength.

[ziyiz-amzn]

Currently, if cx changes replacement image in props, process will not be re-created. It will be a breaking change if it allows re-creation upon props change.

Thus, I think removing image.blob check keeps it non-breaking, meanwhile, it pushes cx to use processor.setImageBlob()