To avoid producing too many draw calls, we could try to make batching algorithm more aggressive
either by tweaking the look-back count (trading frame building time with potential batching wins), or by coming up with an algorithm that is better able to detect batching opportunities. Glenn said during the Berlin allhands that the current algorithm might be more conservative than it should.
Edit: batch breaks are rarely caused by insufficient lookback, see https://bugzilla.mozilla.org/show_bug.cgi?id=1594474#c1.
The way the batching algorithm works at a high level is:
- traverse the created batches starting at the most recently added
- if an incompatble batch intersects with the primitive, bail out and create a new batch
- if a compatble batch is found, add to that batch.
The code for this is all in batch.rs
An example of where this algorithm misses batching opportunities is
|img | |img |
|z=0 | +-----|z=2 |
+----+ |text +----+
When adding the image on the right (z=2), the batching code sees an intersection with the text batch and ends up creating a new image batch. In theory we could attempt to move the text batch before the image on the left (since they don't intersect, their relative order does not matter), which would allow the two images to be on the same batch. Now it's unclear that having a fancier algorithm that can do that would actually translate to significant improvements in practice. We'd probably have to try and see.