What SDK is this related to?

This happens on the Android SDK.

After doing more testing, I noticed that the slow call was actually BitmapDescriptorFactory.fromBitmap(). This method also becomes unpredictable (in terms of run time) after a few hundred calls. I was able to work around this by only generating a BitmapDescriptor once for each marker, but the method should probably run faster anyhow.

(No comment was entered for this change.)

(No comment was entered for this change.)

Any update on this?
I'm currently batch-adding a few hundred MarkerOptions to the map and it takes about 500ms for 250 markers.
In the maps V1 we could batch add many and call populate() once to make them visible. I think a similar approach would be helpful since it seams that each add/remove triggers a whole bunch of stuff in the background!

(No comment was entered for this change.)

 Issue 8005  has been merged into this issue.

Any update on this issue? It's been over 2 years. I would really like to see this fixed or at least improved. It affects basically every single app that displays dynamic data. It should be unacceptable to have this scroll chunkiness when displaying only 20-100 markers when we have the processing power we have now on modern devices, right? I'm assuming the reason this is a technical challenge is because the V2 API is using some kind of IPC-call-per-map-mutation that's adding a huge hit for every 'round trip'. I can imagine it's hard to fix, but there has to be SOME solution to be able to change map data and keep a decent frame rate. Currently the only way to keep 60fps smooth scrolling is to just never change the data on the map.

Thanks!