Improve asynchronous Primitive creation

[mramato]

Update:
While the initial work on this issue is now in master and performance is much better, there are still several things we can do to further improve things. Here are some ideas that we can explore.

• Creating a general WorkerPool class, basically a threadpool for web workers. I could see this potentially being a singleton used to manage concurrency throughout Cesium (Geometry/Imagery/Terrain/etc..).
• Rather than pack all data into Float64Arrays, pack data into arrays of the same type. This will require a bit more bookkeeping, but shouldn't be too hard and will require less memory. This will also allow us to use subarray views in unpackInstancesForCombine rather than the overhead of creating lots of typed arrays.
• The initial call to createGeometry is currently unpacked and can still adds a lot of overhead for certain types of Geometry; this can be fixed by having our Geometry know how to pack themselves or have them store there data in a typed array from the start for each transfer. Pack Geometries before passing to a web worker #2342
• combineGeometry is still one big synchronous step and is just performed in a worker (rather than split up across several workers like createGeometry). I'm not sure if it's possible to refactor it in a way that allows for concurrency

Original Issue:
Currently, creating primitives asynchronously is much slower than doing it in the main thread. Some simple tests shows that a 1.58 MB GeoJSON file takes about 13 seconds to load asynchronously and only 4 seconds when synchronous. (in Chrome). These numbers are more event dramatic in Firefox, 6 compared to 35.

This is most likely due to a very chatty interface for offloading the pipeline and could be fixed with coarser interfaces.

Here's a profile of what the main thread is doing between "drop 10 megs of GeoJSON on globe" and "stuff shows up" when using asynchronous creation.

[pjcozzi]

👍

It would also be worth exploring how to use multiple workers.

[YouLu]

looking forward to it

[mykels]

Is there a plan to load billboards asynchronously? In our application we implemented a simple algorithm for loading batches of billboards at once (for example 3000) and then waiting for a certain timeout to expire before loading the next batch (for example 1500 ms).

[mramato]

@Micha1991, I'm not exactly sure what you are asking. Billboard images are already loaded asynchronously and there's no other part of the process that would cause a block. Please continue this discussion on our forum if you still have questions.