Reasons for moving loading to workers:
Considerations when moving loading and parsing to workers:
Threads cannot share non-binary data structures and these have to be serialized/deserialized. This is a big issue for worker thread based loading as the purpose of loaders is typically to load and parse big datastructures, and main thread deserialization times are often comparable to or even exceed the time required to parse the data in the first place, defeating the value of moving parsing to a worker thread.
The solution is usually to use data types that support ownership transfer (see next section) as much as possible and minimize the amount of non-binary data returned from the parser.
loaders.gl will handle message passing behind the scenes. Loading on a worker thread returns a promise that completes when the worker is done and the data has been transferred back to the main thread.
All worker enabled loaders come with a pre-built, minimal worker "executable" to enable zero-configuration use in applications.
All worker enabled loaders provide separate loader objects to ensure that tree-shaking bundlers will be able to remove the code for the unused case.
Loaders.gl offers loader objects for main thread and worker threads. A simple switch lets you move your loading back to the main thread for easier debugging and benchmarking (comparing speeds to ensure you are gaining the benefits you expect from worker thread based loading).
Through Thread Pool Management it will be possible to start worker threads before they ae needed to minimize worker loading delay when parsing.
It can be valuable to run muliple instances of the same worker thread to leverage multi-core CPUs. Being able to warm-up (pre-iniutilize) the thread pool and set limits of how many threads of each worker type...