Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Time estimate or Size
small
Problem
There are a variety of issues with the time slider in Simularium right now, so here's my stab at trying to fix it!
Some of the issues are described in this ticket, which links to this spreadsheet from the octopus bug bash.
Solution
So I did two changes to address some of the issues we're seeing on the time slider, but I'm open to suggestion if there are other ways to better solve it.
setBuffering(true);
when we skip to a new time. In the current state, when you slide the time slider, it is continuously switching between the buttons showing as spinners and the buttons showing normally, because every time the slider moves to a new frame, we set buffering to true until the frame is received and it gets set as false, which is a weird user experience. While this eliminates that weirdness when you're sliding the slider, it could be an issue if a frame we just jumped to is actually taking a while to load, in which case the loading state where the buttons are spinners wouldn't show up. I couldn't actually get this case to occur through manual testing, but I'm sure it'd be possible if the octopus cluster was really overrun and it was in the process of starting up a new container to handle the increased traffic. If we're worried about this, maybe I could add some logic so we only show the spinners if buffering has held as true for some non-trivial amount of time?onAfterChange
functionality and simplified theonChange
functionality. We were having issues with having the right frame actually get displayed when jumping / sliding around a lot on the slider, and sometimes we would end up in a state where everything was stuck loading. As part of my debugging process, I removed various pieces of functionality to see how they were impacting the performance, and a lot of our problems seemed to be solved when we just directly calledonTimeChange
from the slidersonChange
? I also poked around in some of our other repos that use this component, and none of them were usingonAfterChange
. This code has been this way for a couple years, maybe the reason we needed this extra functionality originally (either because of antd or some of our own code) is no longer relevant?Type of change