I thought we were going to make this scoped with a parent widget instead of having an explicit key?

There will still be a key type. Scoping would be done with an inherited widget, which exists above the render object/layer types.

Do you want that in this PR?

There will still be a key type. Scoping would be done with an inherited widget, which exists above the render object/layer types.

Do you want that in this PR?

Ah okay. I think it would be nice to have the full picture defined somewhere before signing off on the details. It can be a separate pr based on this one or a small design doc.

The design is fairly simple. its "just" an inherited widget and a special constructor.

// new inherited widget type, introduces scoped backdrop. internally caches
// backdrop id.
class BackdropProvider { ... }

// new backdrop filter contructor. internally grabs backdrop id.
BackdropFilter(..., parent:  BackdropProvider.of(context))

Why do we need to specify the parent explicitly? That information exists in the tree, can't we just crawl up to the widget tree to get the closest ancestor of that type?

If you want to hide the lookup that could be deferred to the body itself. What would you call this new backdrop filter constructor? I'm intentionally trying not to change the behavior of the existing filter. You don't want to opt in to using backdrop ids accidentally because it can be very breaking with overlaps.

BackdropFilter.fromParent(filter: ..., child: ...); // grabs BackdropProvider.of(context)

I mentioned it here: flutter/engine#55701 (comment)

I'll fill it out more to show what I was thinking:

Widget build(BuildContext context) {
  return BackdropGroup(
    children:[
      ClipRect(
        child: BackdropFilter(
          filter: ui.ImageFilter.blur(
            sigmaX: 5.0,
            sigmaY: 5.0,
          ),
          child: Container(
            alignment: Alignment.center,
            width: 200.0,
            height: 200.0,
            child: const Text('Hello World'),
          ),
        )
      ),
      ClipRect(
        child: BackdropFilter(
          filter: ui.ImageFilter.blur(
            sigmaX: 5.0,
            sigmaY: 5.0,
          ),
          child: Container(
            alignment: Alignment.center,
            width: 200.0,
            height: 200.0,
            child: const Text('Hello World'),
          ),
        )
      ),
    ]
  );
}

There is no explicit key, there is no new constructor for the backdrop filters, there is no breakage since code without BackdropGroup will behave as it always has, and there is no duplication of information that can be inferred contextually.

That design doesn't allow you to nest backdrop filters that don't use the shared BackdropGroup. Opting in to sharing must be explicit otherwise you limit the usefullness of BackdropGroup

This is important for widgets that incidentally use backdrop filters. For example, imagine a button that used a backdrop filter in an interna saveLayer layer, but nestled in the app I show above. You don't want it to accidentally start reading from the same backdrop as the list items.

That design doesn't allow you to nest backdrop filters that don't use the shared BackdropGroup. Opting in to sharing must be explicit otherwise you limit the usefullness of BackdropGroup

I would say opting out of a group which you are defined in is an exceptional case. The design of the API should be the smoothest/least amount of typing for the most common case.

This is important for widgets that incidentally use backdrop filters. For example, imagine a button that used a backdrop filter in an interna saveLayer layer, but nestled in the app I show above. You don't want it to accidentally start reading from the same backdrop as the list items.

What have our other APIs done? I believe the scenario you're laying out. I'm skeptical that it's that likely or problematic to justify making the API more complicated.

Here's the compromise that leaves us in a better place. Not specifying the group means that it takes the closest ancestor group by default, you can also specify it explicitly.

That isn't a reasonable compromise, as its going to make an opt in performance improvement into an opt out breaking change.

I'ved added the BackdropGroup, the BackdropFilter.shared constructor, and updated the sample code to use the backdrop group instead.

That isn't a reasonable compromise, as its going to make an opt in performance improvement into an opt out breaking change.

It's not a breaking change because the behavior won't change unless a BackdropGroup is added to the widget tree. Are you thinking there would be one group for the whole tree if one isn't supplied above? We should keep the old behavior that they are all independent.

The scenario you are describing would play out like this:
Aaron: Oh man, my client isn't happy because the performance on this scroll view. Time to start profiling...
Narrator: 1 day later...
Aaron: Hmm, looks like it's related to blur performance. I remember hearing about BackdropFilterGroups, that might help. I'll throw everything into one backdrop filter. That's got to be the best peformance.
Narrator: 15 minutes...tick tock
Aaron: Hmm well that is much faster, but why does that one blur look odd. The docstring for BackdropFilterGroups warned that there can be interference between backdrop filters. I'll try opting him out of the group like it said.
Aaron: Bingo!

Or better yet, there will be a whole class of problem scenarios where they could be solved by just breaking up the BackdropFilterGroup, no need to explicitly opt out.

lets GVC about it, easier to explain.