Adds configurable prefetching behavior to OmeZarrLoader. Should (at last!) resolve #126. I think I have this feature working pretty well now, but please pull it and try for yourself!
How it works for users:
When any zarr volume with a time series loads, the loader begins prefetching adjacent time steps. Moving to adjacent time steps gets faster because those steps may already have been requested and received.
When the user switches to z-slice mode and the chunking of the volume affords loading a subset of the volume at higher resolution, the loader begins prefetching adjacent chunks in z. Moving to adjacent z-slices gets faster too.
If both of the above are true, it does both at the same time!
How it works for developers:
RequestQueue now has two "lanes:" regular and low-priority.
The zarr loader uses the regular lane for normal loads and the low-priority lane for prefetches.
All regular requests must be started before any low-priority requests get to go.
The low-priority lane has its own concurrency limit, which may be set lower (but cannot be set higher!) than the limit for the regular lane. This allows the user to ensure that the queue always leaves some space open for new regular requests to begin immediately.
OmeZarrLoader now properly uses SubscribableRequestQueue, which has new method arguments to use RequestQueue's new priority features.
OmeZarrLoader has two new options to configure prefetching behavior:
maxPrefetchDistance is a Vector4 representing the maximum number of chunks to prefetch outwards in both directions of a given dimension. (X and Y are of course not currently used in practice, but they're still in there for just in case.) For instance, if a load requests chunks with z coords 3 and 4 and maxPrefetchDistance.z is 2, the loader will prefetch similar chunks with z coords 1, 2, 5, and 6. The w component is time.
maxPrefetchChunks is the max number of total prefetch requests that can be made after any load. The loader will always stop issuing prefetch requests at this number even if maxPrefetchDistance would allow loading more.
Other changes:
OmeZarrLoader.ts was getting long and cumbersome, and began with a growing string of items that made the actual beginning of the OmeZarrLoader class declaration hard to find. I moved some of these items into their own files in a new /zarr_utils subdirectory:
WrappedStore.ts for the object that lets us link into zarrita's low-level chunk request behavior.
types.ts for stray shared types and the big declaration of the OME-Zarr JSON metadata format.
/zarr_utils also has one brand new item: ChunkPrefetchIterator encapsulates the somewhat complicated process of identifying which chunks can and should be prefetched and in what order.
Did a bit of refactoring in OmeZarrLoader to make all of the above easier, notably adding a couple methods for convenient reshuffling of dimension-ordered arrays.
Adds configurable prefetching behavior to
OmeZarrLoader. Should (at last!) resolve #126. I think I have this feature working pretty well now, but please pull it and try for yourself!How it works for users:
How it works for developers:
RequestQueuenow has two "lanes:" regular and low-priority.OmeZarrLoadernow properly usesSubscribableRequestQueue, which has new method arguments to useRequestQueue's new priority features.OmeZarrLoaderhas two new options to configure prefetching behavior:maxPrefetchDistanceis aVector4representing the maximum number of chunks to prefetch outwards in both directions of a given dimension. (X and Y are of course not currently used in practice, but they're still in there for just in case.) For instance, if a load requests chunks with z coords 3 and 4 andmaxPrefetchDistance.zis 2, the loader will prefetch similar chunks with z coords 1, 2, 5, and 6. Thewcomponent is time.maxPrefetchChunksis the max number of total prefetch requests that can be made after any load. The loader will always stop issuing prefetch requests at this number even ifmaxPrefetchDistancewould allow loading more.Other changes:
OmeZarrLoaderclass declaration hard to find. I moved some of these items into their own files in a new /zarr_utils subdirectory:ChunkPrefetchIteratorencapsulates the somewhat complicated process of identifying which chunks can and should be prefetched and in what order.OmeZarrLoaderto make all of the above easier, notably adding a couple methods for convenient reshuffling of dimension-ordered arrays.