search

spacetelescope / jdaviz

JWST astronomical data analysis tools in the Jupyter platform
https://jdaviz.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
134 stars 72 forks source link

Cube slider desyncs with rapid scrubbing #244

Closed PatrickOgle closed 2 years ago

PatrickOgle commented 4 years ago

When rapidly moving the cube slice slider in Cubeviz, the viewer displays lag behind and sometimes freeze.

mariobuikhuizen commented 4 years ago

Should be fixed with https://github.com/glue-viz/glue-jupyter/pull/200

duytnguyendtn commented 4 years ago

266 definitely helps mitigate this bug, but I caution us from thinking #266 solves this bug. Having an arbitrary delay is just that, arbitrary. If the slices get bigger, it's entirely possible for this to get more delayed again, and therefore desynced.

For a more permanent solution (after the 1.0 release obviously ;P) I think we should think of another solution. Here are a few I'm thinking of:

  1. There should be a way for the system to know if it's getting "out of sync". In that there should be communication that shows where the slider actually is, and what slice is actually being rendered. In the event those are desynced, at the very bare minimum, maybe show a loading icon to show that the system is thinking (Pardon the poor photoshop, I'm no Jen Kotler!) image

I think the crux of the problem is we are still rendering the ENTIRE image each time a slice is selected. Adding a delay (i.e. skipping some slices) definitely helps, but we're still limited by the size of each slice. Think of trying to scrub through a composite Roman (RST) cube! 100x the size of a Hubble slice, I can't even imagine. Therefore I'm thinking we should consider scalable behavior that is "slice independent."

  1. Lower Res Rendering: I don't know how computationally expensive this would be, but maybe do something like Google Maps, where it renders the slices at a super low resolution first, and if the user sits on a particular slice for a while, and only if the user sits on it for a while, does it actually render full res. Think about YouTube scrubbing JEpZ
  2. The slider button (the circle itself) should show the actual position the viewers are on. This means if the user whips back and forth, the circle will lag behind the cursor: vegas-trimmer-scrubbing-04
  3. Preview Window: There is a small window that shows a lower res rendering of the slice and only fully renders all three viewers once the user lets go: videochapters

Just some thoughts; thanks!

astrofrog commented 4 years ago

Just a quick note - glue never renders the whole image but instead accesses a fixed resolution buffer from the data. This means we can load a 1Tb image and it should behave fine. This works well provided the data is on a disk with good random access (typically SSDs) but does get a bit slower on spinning drives, since it relies on accessing each pixel individually from memory mapped arrays.

astrofrog commented 4 years ago

Having said this, throttling the slider is definitely a good idea!

rosteen commented 2 years ago

The slider functionality has been updated and moved into a plugin since this issue was made. I just tried abusing it by moving the slider around as rapidly as possible, and it seems to me that it handles that gracefully and as expected. I'm closing this as solved.