Profile: https://share.firefox.dev/3hbJr5H

WebGLContext::DrawArraysInstanced seems to spend a fair amount of time allocating and freeing things via ScopedResolveTexturesForDraw.

I found this on the Proxx-Tables-Canvas benchmark (bug 1798923): https://grandprixbench.netlify.app/?suites=Proxx-Tables-Canvas

Kelsey, you've been in this code quite a bit. Are these memory allocations avoidable, or can the number of texUnits be known up-front? ScopedResolveTexturesForDraw::ScopedResolveTexturesForDraw is also profiling in a weird way: the profiler seems to show that the function invokes itself and also can allocate multiple maps in the same call -- perhaps that's just showing that the reserve amount has been exceeded.

We should just reuse the allocations somehow.
The max size is known and small, I'm mostly using map for ergonomics.

I'm tempted to just have this be a static thread_local, but we can just tag it off of the this object.

Also showing up kinda hot there is overhead around these four related commands:

• SetEnabled
• Clear
• ClearColor
• Scissor

Feels like we're ending up doing something like:

for () {
  Enable(SCISSOR_TEST)
  Scissor(x,y,...)
  ClearColor(r,g,b,a)
  Clear(COLOR)
  Disable(SCISSOR_TEST)
}

You can imagine us e.g. lazily combining ClearColor+Clear into Clear(flags, r,g,b,a, d,s), and/or eliding unused Enables/Disables.
Deser overhead is cheap but not free, and it does show up here weighing things down.

While that profile link does make it look like we're spending 15% in this func, that's because we're dropping samples that are waiting on events, so this is closer to a 2% win, all else equal.

https://hg.mozilla.org/mozilla-central/rev/25b53dd457af

== Change summary for alert #36053 (as of Sun, 13 Nov 2022 01:24:52 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36053