You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the mousewheel, scroll the timeline vertically. Observe that while scrolling up or down, the timeline scrolls at a consistent speed as expected.
Using the mousewheel, scroll down until you're at around the "Task 12" group.
By clicking and dragging on the timeline, scroll horizontally a few pixels. Observe that the timeline jumps and now you're looking at ~"Task 84".
Slowly scroll back up the page. Observe that once you get to around "Task 25", scrolling leaps in large bounds, it's no longer smooth.
Once back to the top of the timeline, try scrolling diagonally down. Observe that the scrolling experience is not at all smooth.
Cause:
Group._updateItemsInRange sets this.visibleItems to [] if the group itself is not visible.
Group._calculateHeight only operates on this.visibleItems, and if there are no such items it will set the height to this.props.label.height, which can be significantly smaller than the stacked height of items.
Possible solutions:
Have Group._calculateHeight bail if the group is not visible, assuming the height is unchanged. If the timeline is scrolled horizontally far enough that the items within the visible range change, there will still be a jump when the group becomes visible again, but this only happens when the user scrolls up.
Have Group._updateItemsInRange return the items that are horizontally within range even if the group is offscreen. This will reduce performance by restacking items for off-screen groups. As items on off-screen groups enter and exit the visible range, the timeline may jump considerably due to all their heights changing off-screen.
I suggest option #1. I think the current design means that some amount of jumping is inevitable when the screen is scrolled horizontally, since the height of the groups is changing. I think with option #1 these jumps will have less of an impact on the user experience. It will also maintain the current performance. I have future changes that I'm planning which will further lessen this impact.
The text was updated successfully, but these errors were encountered:
Steps to reproduce:
Cause:
Group._updateItemsInRange
setsthis.visibleItems
to[]
if the group itself is not visible.Group._calculateHeight
only operates onthis.visibleItems
, and if there are no such items it will set the height tothis.props.label.height
, which can be significantly smaller than the stacked height of items.Possible solutions:
Group._calculateHeight
bail if the group is not visible, assuming the height is unchanged. If the timeline is scrolled horizontally far enough that the items within the visible range change, there will still be a jump when the group becomes visible again, but this only happens when the user scrolls up.Group._updateItemsInRange
return the items that are horizontally within range even if the group is offscreen. This will reduce performance by restacking items for off-screen groups. As items on off-screen groups enter and exit the visible range, the timeline may jump considerably due to all their heights changing off-screen.I suggest option #1. I think the current design means that some amount of jumping is inevitable when the screen is scrolled horizontally, since the height of the groups is changing. I think with option #1 these jumps will have less of an impact on the user experience. It will also maintain the current performance. I have future changes that I'm planning which will further lessen this impact.
The text was updated successfully, but these errors were encountered: