Unfortunately, the current implementation requires explicitly creating and assigning a new clip for clipping to work properly. This is because we are rendering the filtered backdrop in the backdrop space, but we want to apply a clip that exists in some other space (in this case a new space with a perspective transform).

I don't think this is feasible as a general implementation between any two spatial nodes (even if connected). I think it can only be done between surfaces, since we know that at that point the transform hierarchy will be flattened (projected) at those points. Otherwise it's possible to get into situations where we have a series of intermediate transforms without a surface, and projecting them gives incorrect results.

I haven't reviewed most of this file yet - will come back to it once we discuss some of the other comments and I have a better understanding of the patch details :)

Let's add some comments on when / why this would be used.

Probably just lack of understanding the spec / details, but it's not really clear to me why backdrop is a primitive, rather than a property on a stacking context? It seems like that might simplify parts of the implementation / fit in better conceptually, although it's probably just me not understanding the details of the patch yet.

Why is this and what implications does it have for existing code?

Ah good point, I don't think I am actually using this function anymore. I was using this to project the bounding rect of the element with backdrop-filter onto the backdrop; however, I was getting incorrect results, probably due to what you are mentioning here.

I replaced this by using SpaceMapper to project the rect from the backdrop-filter element space to the root space and then from the root space to the backdrop space. Although, projecting between surfaces seems like a more sound approach.

I think it would be okay to move it to the stacking context in the public API, but internally it seemed simpler to use a primitive. It seems like a common use-case to apply backdrop-filter to an element which has a size but no content. For this, we would need to add a bit of extra logic to the visibility update pass to ensure a picture isn't culled from the scene due to having no child primitives. Primitives also handle a lot of the clipping logic, which would need to be duplicated for clipping the filtered backdrop.

I am open to moving this to the stacking context but it comes with a different set of tradeoffs (maybe better tradeoffs? I'm not sure yet).

Pictures track their render task by keeping the render task ID in its surface's RenderTasks. Currently I don't think we have any cases where the result of a picture task is used multiple times. With this patch we want to use the result twice: once to render the backdrop and a second time to render the filtered backdrop.

If we do end up blitting a dependency, we update the render tasks's dependency to reflect the new id of the blit task, but this does not update the render task ID in a picture's surface. It could be that the solution is to check if the parent task is a picture task and swap out the render task ID on the surface, but I'm not sure of the implications of that, so I added this as a temporary workaround.

Is this still used? I thought we made the capture implicit?

Looks like I forgot to remove hits. The capture is implicit now.