Add debug check for platform view filter layer conflict - #188542

These if-checks feel brittle. My understanding is PlatformViewLayer should not have filter/blend layer ancestors, Is it better to add a signal in the Layer interface which is set for filter/blend layers and can be checked here instead?

Yeah, that could be a way. When I was implementing this, I thought this would be a focused touch considering that it only affects the platform view and the kind of filter layer is stable. But if new filter layer could be added in the future, adding a common interface would indeed be helpful as a reminder.

Should this debug check live here? What if a PlatformViewLayer with a high enough cached depth is grafted onto a filter layer's subtree, so redepthChildren is never called?

Yeah, this is a valid concern. I just checked that redepthChildren will only be called whenever a child's depth <= its parent's depth.
And I also noticed a potential bug, if a subtree can be moved to another layer, and if the depth of the subtree root is already greater than the new parent's, then the depth of the whole subtree won't be updated. It means depth can be discontinuous in a layer path? Is this by design?

And I think this is best place I can think of. It covers all the cases except moving a subtree containing platform view to a layer with lower depth via global key?

I agree this isn't the right place. Does the assert work in addToScene where the layer tree should be stable?

Is this by design?

Yes. depth represents a partial order so it's exact value doesn't matter.

Just tested addToScene, not working.
It's only called during the very early stage and the platform view layer doesn't have the full ancestors list.

I agree this isn't the right place. Does the assert work in addToScene where the layer tree should be stable?

Is this by design?

Yes. depth represents a partial order so it's exact value doesn't matter.

Are there existing documentation supporting this assertion? Different embedders implement platform views differently so I'm not sure this is a problem for all embedders.

In the PlatformViewLayer docs:

/// A layer that shows an embedded [UIView](https://developer.apple.com/documentation/uikit/uiview)
/// on iOS.

And https://docs.flutter.dev/platform-integration/ios/platform-views#composition-limitations

Composition limitations
There are some limitations when composing iOS Platform Views.

The [ShaderMask](https://api.flutter.dev/flutter/foundation/ShaderMask.html) and [ColorFiltered](https://api.flutter.dev/flutter/foundation/ColorFiltered.html) widgets are not supported.
The [BackdropFilter](https://api.flutter.dev/flutter/foundation/BackdropFilter.html) widget is supported, but there are some limitations on how it can be used. For more details, check out the [iOS Platform View Backdrop Filter Blur design doc](https://flutter.dev/go/ios-platformview-backdrop-filter-blur).

And for ImageFilter, I think it has the same limitation.

I think PlatformViewLayer is only for iOS (and macOS?) based on these docs and https://docs.flutter.dev/platform-integration/android/platform-views#choosing-an-implementation. So, adding this assertion should not affect the texture rendering native views that will work with these filters.

However I think I need to update the cupertino bottom sheet PR. Because hasPlatformView=true should not disable the animation optimization for Android which uses texture for platform views.

Also, PlatformViewLayer is the ONLY layer that always returns

  @override
  bool supportsRasterization() {
    return false;
  }

Even if the other embedders could use it, it's for the content that doesn't support raterization and cannot be sent to the filter shaders.