Ideation for removing stalls, improving time to tiles load

[gkjohnson]

Related to #604

Aimed primarily at improving the time-to-completion and removing load stalls for Googles Photorealistic tiles.

Increase Download Queue Job Count #634

The number of "jobs" that can be run at once is a bottle neck in some cases - especially for downloads. Increasing number of jobs may help but risks performing too much work per frame. Possibly adding bounds for the number of jobs started and / or ended per frame may be more helpful here (ie an initial "fetch" call can be a bit expensive).

Download Tiles Before Needed #633

A lot of the delay during the initial load comes from waiting for parent tile to be completely loaded before loading any child tiles. The next layer of child tiles could be "preloaded" so they're ready to start loading even when there's one parent tile left that hasn't finished loading / parsing.

Improve "Skip" Traversal Options #480

See skipping settings for cesium's tiles - current issues with the threshold setting means that when the the camera zooms out and parent tiles must load then the tiles "pop" to the parent LoDs.

• skipLevels: skip a set of tiles based on depth
• skipScreenSpaceErrorFactor: seems to be similar to this projects errorThreshold - but this causes a "jump" when a parent suddenly is in view. Same thing happens when "loadSiblings" is false
• Dynamic screen space error options: increase the error target as we get further from the camera

Locally Cache Geometry Data

Using local caches (IndexedDB, etc) geometry could be saved to disk so it can be quickly loaded again on camera shift or page reload. This can be done with a plugin. We would have to respect the time to expire headers, though.

The browser cache should be able to passively take care of this, though, so it may not be worth it - but it will skip any header requests that have to happen.

Data Preupload #490

Some stalls can come from geometry and texture decode / upload. If any of these operations can happen asynchronously then it may make sense to trigger an upload a frame or two before rendering so the render stage does not have to stall waiting for the upload so the object can be rendered. Or we can trigger an upload at a more opportune time - ie immediately after the frame as rendered.

edit it's possible data pre upload could still be valuable since when tiles "refine" and children are displayed the GPU will suddenly have a lot of new geometry and texture data to upload all at once. If the textures and geometry are uploaded a little bit at a time then we could avoid these sudden stalls when lots of tiles load in at once (ie when using a large number of parse queue jobs). Performance should be checked here first to see where the time is going when parse queue is allowed to perform a lot of jobs at once.

It's possible we would also want to afford a separate queue / promise after a tile is considered finished by the parse queue so this work can be done / awaited without blocking adding more parse queue jobs.