Improve texture streaming to reduce

[Geenz]

Texture streaming can be pretty brutal in terms of performance. Here are some examples:

• Microstutters can occur when VRAM is low but overall frame rate can be high
• Memory usage can be higher compared to older viewers, for example. 6.6.17. This is usually going to be due to texture usage.
• There can be some thread contention between loading threads and the main thread with textures

Generally these issues have been difficult to nail down.

Test Plan

TBD.

[PhilipRosedale]

Can I get more detail on the changes you'd propose, how long they will take, and how we will test that they work. Do we have a metric for how long it takes to load all the textures needed in a scene, for example?

[Geenz]

We don't have metrics - and I'd be looking to add metrics in the viewer before we ship something like this so we can better A/B test with live data. That part should be non-negotiable IMO. I'm already looking at adding that to the other metrics we're looking at shipping with GLTF Mesh Import.

Generally what I'm thinking is:

• Move texture loading out from coroutines and into a work queue (or similar multithreaded job system)
  • This would make texture downloads and loading more generally less blocking on the main thread where we do all of our rendering. We already offload some stuff into workers just via HTTP requests - but we can still do better.
• Improve our logic on determining what resolution we actually need to have loaded into VRAM. We're most of the way there, but there's still outliers that we need to deal with.
• The most difficult part - figure out why we experience micro stutters in low VRAM scenarios compared to FS 6.6.17. This seems to be a direct result of how we've changed texture streaming with V7.