Zarr Loader Decoding Off Main Thread

[ilan-gold]

Currently it appears that decoding the responses blocks the main thread so it would be good to use a (few) worker(s) to unblock. Investigation needs to be done....

[manzt]

Just want to put own my current observations here and list things that I think should be discussed/investigated.

Both zarr.js and geotiff.js use pako for decoding arrays encoded via Zlib. However, the libraries differ in that geotiff.js decodes arrayBuffers on separate threads using web workers (via Pool) but zarr.js decodes on the "main thread". I think this difference is what is responsible for high-latency (janky) interactions with the zarr-based loaders, but understanding these performance differences will take some careful investigation. Below are the two tradeoffs I foresee in the different implementation approaches.

1.) Decoding on main-thread (as in zarr.js) means that UI interactions are likely blocked if many tiles need to be decoded. This can lead to some "janky" interactions when interacting with the deck.gl context, BUT the tiles seem to load quickly since there is no transferring of arrayBuffers between threads.

2.) Interactions with the deck.gl context "feel" more fluid with the geotiff.js-based loaders since all decoding done "off main thread", but the time to see a full resolution tile is noticeable compared to the zarr.js. I believe this is due to the overhead of transferring the large arrayBuffers between threads.

All in all, it is nice that we actually have these two loaders to test which strategy makes the most sense!