Map-Zoom Performance Issue

[skearns64]

Kibana version: 5.0 Beta 1

Elasticsearch version: 5.0 Beta 1

Server OS version: MacOS Sierra

Browser: Chroms

Original install method (e.g. download page, yum, from source, etc.): Tar.gz

Description of the problem including expected versus actual behavior:
When fully-zoomed in, and I click the "fit data bounds" button, it appears that Kibana makes a request for the whole data area with the same precision as the fully-zoomed in version, which pulls back a tremendous amount of highly granular data. Attempting to display this effectively hangs my browser for 10-15 seconds.
Once this high full-resolution data has been pulled and displayed, Kibana re-orients, and pulls the appropriate precision data.

It seems quite possible, that if I had more data, or less memory, it could crash Chrome.

Steps to reproduce:
Here’s the steps I took to reproduce a maps performance problem. On any dataset with worldwide geo data, create tile map.

1. Zoom all the way in on area of the map that has datapoints.
2. Click the "fit data bounds" button, which zooms you out.
3. Observe performance problem that presents like this:

• Kibana runs a whole-world query with the same precision number that was used on the way-zoomed in area.
• You can briefly see these highly detailed points being rendered on the screen, then it refreshes and shows the data with the appropriate zoom level.

[thomasneirynck]

I can reproduce the same visual effect on 4.6.

Kibana actually does not send two queries.

• When you are zoomed all the way in, Kibana has already requested all the data (worldwide), but is only rendering a small selection of it (the responses that fit inside the bounds of the map).
• When you pull out, Kibana renders ALL of the data at that high precision (ie. creating a SVG circle for each response), causing the browser to hang.

Either way, this is kind of a nasty issue. You would want Kibana to take into account the current extent of the bounds.

This issue duplicates #8087 I think.

[thomasneirynck]

@skearns64 I'm pretty sure this duplicates #8087 so I'll go ahead an close this. Please reopen if you think this is different.