Performance issues caused by high amounts of draw calls.

100 draw calls per frames is a reasonable amount (not a hard limit). Multiple hundreds, however, tend to cause excessive CPU usage in the renderer.

I added some logging in the batching phase to get a sense of proportions between various batch breaking reasons in the alpha pass:

• When searching for compatible batches, a modest majority (typically ~60%) of incompatibilities come from different shaders.
• When searching for compatible batches, a lot (typically ~40%) of incompatibilities come from using the same shader but different textures.
• When searching for compatible batches, almost no incompatibilities come from using the same shader but different blend modes.
• We run into a lookback limit of 10 (current default) in 3 to 10% of alpha batch breaks.
• We run into a lookback limit of 20 in 0 to 6% of alpha batch breaks.
• We run into a lookback limit of 50 in 0 to 2% of alpha batch breaks.
• We run into a lookback limit of 5 in 5 to 15% of alpha batch breaks .

The takeaways for me are:

• On the workloads I tested, the lookback limit has a rather small impact.
• Most batch breaks come from primitives overlapping with a recent incompatible batch rectangle (worth checking whether these are as tight as they could be).
• We break batches because of incompatble textures more often than I expected.

I had another look at batching, concentrating on some bad cases:

• (A) https://forum.xda-developers.com/redmi-note-3/development from bug 1480945
• (B) https://letterboxd.com/mariamicia13/list/for-when-you-dont-have-too-much-time-but/ from bug 1520401
• A few other pages which turned out very similar to (A).

In (A) we break alpha batches mostly because we are alternating between text and image shaders, which is a common scenario for real world pages that have poor batching.
In (B) we break alpha batches a lot due to alternating between image and solid shaders.

There's another interesting effect I observed on (B): it has a lot of images causing the texture cache to allocate multiple texture arrays. When visiting the page on an already occupied/fragmented cache, images end up spread between many different texture arrays and we break more batches because we hit the lookback limit when searching for an image batch with the same texture. I suspect the effect of fragmentation on batching can be observed in many other pages with many medium/large images like the youtube front page.

On pages where the texture cache doesn't have a lot of texture arrays, the majority of the time we traverse no more than 3 batches before either finding one that is compatible or intersecting with an incompatible one. This echoes what I wrote earlier in comment 1: the lookback limit (10) has a rather minor effect in general. It also means that even if we crank it up to, say, 200 or remove the limit entirely, it won't affect frame building performance much in the general case. Bumping the limit does save a few batches every now and then, so I think that at least on platforms where the cost of a draw call is very high (low end intel on windows/ANGLE) we should bump the limit. Also in the cases where the cache has a lot of textures it reduces the draw calls count some more.

Drawing small solid primitives with the image brush shader or a multi-brush shader that can do both would help in some pages such as (B). The more common issue is (A), unfortunately unifying the text and image shader is more complicated, although doable (see bug 1615613).