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
I could see that if we're initializing a CalendarPickerView to select a date in the span of 100 years, 5000+ week rows are built at the same time. This creates a noticeable lag of 10+ seconds in an LG Nexus 4. This could be optimized to build only the visible rows at init and build the other rows as user scrolls.
The text was updated successfully, but these errors were encountered:
This widget is definitely not intended for use with a 100 year window. We do all of the date math up front so that scrolling is as fast as it can be. That said, PRs welcome...if you're able to come up with a way to defer the date math and keep scrolling performance good, I'm all ears.
As an alternative you might want to have a ViewPager with one page per-year. Scrolling through 100 years vertically isn't the best UX depending on how far you wanted to go.
I could see that if we're initializing a
CalendarPickerView
to select a date in the span of 100 years, 5000+ week rows are built at the same time. This creates a noticeable lag of 10+ seconds in an LG Nexus 4. This could be optimized to build only the visible rows at init and build the other rows as user scrolls.The text was updated successfully, but these errors were encountered: