RequestScheduler starves imagery requests for 3D Tiles

[mramato]

The NYC demo loads all 3D Tiles tiles before loading any imagery. This is really noticeable on slow connections or slower browsers (Firefox and Chrome throttles show the issue).

http://localhost:8080/Apps/Sandcastle/index.html?src=3D%20Tiles%20Feature%20Picking.html&label=All

Our theory is that since the camera starts at the location of the tileset, the position of the root imagery tile is so far away that it loads it last in the queue. We think something similar would happen with a large 3D tileset or terrain as well.

This makes some demos look really bad during load, but I'm not sure what the level of effort (or priority) for fixing this should be compared to other efforts.

CC @pjcozzi @lilleyse

[lilleyse]

Two ideas for fixing this:

• Create priority buckets based on request type (imagery, terrain, 3D Tiles)
• Prioritize by distance from bounding sphere rather than distance from the tile's center.

[hpinkos]

Not sure if it's related, but the same thing seems to happen to terrain

[mramato]

@hpinkos I would be really surprised if it weren't the same exact problem.

[lilleyse]

I think this might only be a problem in unbuilt versions of Cesium. Compare built with unbuilt.

On the unbuilt version I see the imagery start to load in only after all the .js files have been loaded. Is imagery waiting on a web worker or something?

[lilleyse]

Though the priority ordering could still be better and I have a possible fix coming.

[mramato]

Terrain/Imagery is definitely waiting on a worker, but keep in mind that Chrome will only load so many files at a time, so the fact that JS files are being loaded is starving other requests too. So I definitely expect performance to be worse with the unbuilt version. This is one of the reasons we should always do profile/performance testing against the built version of Cesium; it's a huge difference.

[lilleyse]

Hm so I guess the problem is that 3D Tiles requests are fighting with JS requests, which means it takes longer for imagery to begin. Is that something that we can fix?

[mramato]

Hm so I guess the problem is that 3D Tiles requests are fighting with JS requests, which means it takes longer for imagery to begin. Is that something that we can fix?

Not really (in code anyway). HTTP/2 fixes it because browsers will no longer limit to 6 requests at once.

[mramato]

This was pre-streaming overhaul and I would consider it OBE.