We should have probably added this benchmark back when we fixed #92366 by adding RTrees to DisplayList in flutter/engine#38429 so that we could track a number of changes that were made to the code - some potentially positive, some potentially regressing.

In particular, I recently ran a local copy of the benchmark from #92366 and discovered that not only had we lost almost all of the gains, but the app now takes up to 20 seconds to draw its first frame. The root cause is an oversight in an old PR that added fine-grained bounds when drawing one DL into another in flutter/engine#37451 and any case that would cause such a DL -> DL recording. At the time it was added, there weren't any cases where we might do that, but in the intervening time we've added a couple of cases.

• Impeller has been rendering layer trees by recording the whole tree into a tree-wide DL. If there is a DLLayer that has a very large DL in it, we will iterate over a large number of operations that might not even pass the culling into the frame-sized tree DL.
• Embedders have been recording parts of a tree into DisplayLists using the DisplayListEmbedderViewSlice

When these things happen for the test case mentioned above, 300,000+ drawline calls, that all overlap are iterated and consolidated into a single rectangle somewhat quadratically causing a huge regression.

Some work is being done that will reduce some of these cases, including:

• Impeller is switching over to a direct implementation of DlCanvas for rendering the layer tree which will avoid recording a huge DL into another.
• @knopp recently modified the consolidation of rectangles to use a DlRegion object which greatly improved its performance, but still doesn't help as much as simply reducing the culling rect to use to iterate the bounds when we are transferring them from one DL to another.

After this benchmark lands, I will be landing a 1-line fix for the biggest cause of the regression here - the fact that iterating the rtree bounds inside DlCanvasToReceiver does not provide the cull rect. (see #133437)

We should also consider punting on the fine grained bounds for some DisplayLists, particularly if they contain quite a lot of rendering calls. (see #133436)