Addresses #1578 (not closing for now until we can confirm it's sufficient), and supersedes #1583 and #1635.
Since the debounce behaviour depends directly on the kind of provider used, I ended up injecting a viewerConfig object into the DataContext. This gives a way for providers to configure the viewer to their liking, and for provider consumers to override the configuration as they see fit through a viewerConfig prop.
For now viewerConfig has a single property: slicingTiming to configure the debounce delay on the slicing sliders. I chose a generic name (instead of debounceDelay) in case we need to add a slicingStrategy property in the future to allow throttling instead of debouncing.
Some initial testing seems to show that a slicingTiming of 20ms for h5wasm providers allows for the slicing to be smooth with small images, and also limits the lag with very large images. Removing the debounce completely or switching to a throttling strategy doesn't yield as good results with large images and doesn't seem needed anyway with small images, but do test @bmaranville and let me know if you disagree.
The dataset you use as a demo in #1578 should work very nicely for testing but if you'd like to test with a stack of large images, I recommend kevlar.h5 (with a log scale for the color map). You'll notice that the UI is a bit laggy when the slider moves while a slice is being rendered (because the visualization takes more than 20ms to render), but I think the amount of lag remains acceptable given the size of the images.
From here on, I need to know three things:
Does the whole viewerConfig approach make sense?
Is a customisable slicingTiming enough to address #1578?
Is 20ms a good default for h5wasm (i.e. a compromise between smooth slicing for small images and limited lag for large images)?
FYI, the debounce delay remains unchanged for h5grove and HSDS (250ms).
Addresses #1578 (not closing for now until we can confirm it's sufficient), and supersedes #1583 and #1635.
Since the debounce behaviour depends directly on the kind of provider used, I ended up injecting a
viewerConfig
object into theDataContext
. This gives a way for providers to configure the viewer to their liking, and for provider consumers to override the configuration as they see fit through aviewerConfig
prop.For now
viewerConfig
has a single property:slicingTiming
to configure the debounce delay on the slicing sliders. I chose a generic name (instead ofdebounceDelay
) in case we need to add aslicingStrategy
property in the future to allow throttling instead of debouncing.Some initial testing seems to show that a
slicingTiming
of 20ms for h5wasm providers allows for the slicing to be smooth with small images, and also limits the lag with very large images. Removing the debounce completely or switching to a throttling strategy doesn't yield as good results with large images and doesn't seem needed anyway with small images, but do test @bmaranville and let me know if you disagree.The dataset you use as a demo in #1578 should work very nicely for testing but if you'd like to test with a stack of large images, I recommend
kevlar.h5
(with a log scale for the color map). You'll notice that the UI is a bit laggy when the slider moves while a slice is being rendered (because the visualization takes more than 20ms to render), but I think the amount of lag remains acceptable given the size of the images.From here on, I need to know three things:
viewerConfig
approach make sense?slicingTiming
enough to address #1578?