Pinging @elastic/kibana-gis (Team:Geo)

Thanks for making the changes that we discussed on Slack. It looks good! 🎉

LGTM
One question, Im sure you thought about it and there is a reason. One of the things people expect from time slider is the ability to horizontally drag and manually play. In the current implementation, users can only click the arrows. it harder to see in a smooth way the changes there are no overlapping it immediately jump to the next interval. I'm guessing it is a decision based on performance?

LGTM
One question, Im sure you thought about it and there is a reason. One of the things people expect from time slider is the ability to horizontally drag and manually play. In the current implementation, users can only click the arrows. it harder to see in a smooth way the changes there are no overlapping it immediately jump to the next interval. I'm guessing it is a decision based on performance?

Yeah @AlonaNadler.

We're planning incremental improvements for the timeslider.
We do not want to release playback without a smooth playback experience.

Current milestones we're planning right now look like these:

1. Step through a time range with a time slice.
2. Seamless playback (and sliding manual drag) of the time slice across the time range.
3. Add context and interactivity with a histogram of the time range.

We're going to close this. Thx for all the feedback - on and offline.

@flash1293 had prepared an outline for how a timeslider could behave on a dashboard, and the implications wrt implementing this. https://gist.github.com/flash1293/3a9cf36c331e3f59ed85f0843e68f94e

It makes roughly a similar determination for dashboards as we're doing here for Maps:

• prefetching will be hard, especially for aggregated data, which is the default for most visualizations on a dashboard. The same concerns exist for Maps, and we will not want to explicitly address it. That's why any prefetching we see as feasible in the near-term would only focus on layers with individual documents.
• client-side caching: this could/should happen transparently. @flash1293 proposes the existing client-side cache, something which Maps can leverage too for e.g. choropleth maps, where the relevant data is just term-aggs. In addition, Maps can leverage the transparent client-side caching of tiling the data as well. This is an optimization that already will be in effect when toggling back&forth between timeslices when the data is tiled (ie. using the .mvt format).

@flash1293 also proposed a "third" "hardest" way, which would combine caching and pre-fetching somewhat "automagically". That is not something we're entertaining short term for the Maps implementation.

For completeness, wrt prefetching: The first PR for the Maps timeslider, #99661, removes any pre-fetching logic. This because we are running in more edge-cases than anticipated. We're hoping to dial in prefetch optimizations at a later time.

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 98355 or prevent reminders by adding the backport:skip label.