Why is Bing Maps API mouse click event so slow for mobile?

Question

The mouse click event has a long delay on it when used on mobile devices, or emulated through Edge/Chrome dev tools. How can this delay be removed please?
https://www.bing.com/api/maps/sdkrelease/mapcontrol/isdk/mapmouseevents#JS
You'll notice the delay using the demo above.
This is made worse when I have a number of polygons that can be selected by the user. A user taps and then 1 second goes by before the click event changes the colour of the selected polygon. It's gives a really bad user experience.

Hopefully someone knows what Microsoft did to make the event run slower on mobile and how to undo it please.
Thanks.
Gary.

P.S. Why are there still no tags in this forum for Bing Maps API?

Answer 1

Summarizing the cause and solution as discussed in the comments.

Cause: The primary cause is that the map is rendered on an HTML5 canvas and there is no native mouse events for individual items rendered on the canvas. As such the Bing Maps Web SDK has code to handle this. Everything works as expected when using a mouse. When using a touch screen, on a mobile device or computer, the right click event maps to a long press. In order to support the right click/long press event, there the firing of the click event has to wait a period of time to make sure the user isn't trying to do a long press.

Solutions: Use a different event, such as mouse down or mouse up as these don't need to do any calculations/waiting.

Some history for fun: The Bing maps Web SDK was released 7+ years ago. I was the program manager for the SDK. Initial development took over a year, that's the era of technology used when this SDK was designed and needs to be backwards compatible for. A goal was to be able to support rendering a lot more points on the map. All web maps up until then were using traditional DOM elements for rendering (images/svgs) which would run into performance problems after a few hundred shapes were added to the map. HTML5 browser adoption was on the rise and predicted that by the time we finished development, would be within our minimum threshold for market share support. At that time I recall having a tough discussion around not officially supporting IE10 as HTML5 performance was horrible, and its market share was decreasing at a fast pace. Being Microsoft, we knew that whichever browsers we committed to supporting, we would need to support for a long time. Every time we tried to remove support for a browser previously in other map SDKs there was always a decent number of customers who were stuck on the older browser for some reason, like working on a machine that was locked down, or some legacy product that embedded it that can't be updated. Most, if not all of the Bing Maps Web SDK features still work today on the original set of browsers as documented here. When we were doing development, web worker and WebGL support was low (~56% of market share) and not an option, so we had to use the HTML5 canvas directly with CPU level calculations (UI thread). We had to be creative in how we balanced stability and performance. Supporting mouse events was an interesting challenge and the solution the dev team came up with is pretty cool and comes from an old school gaming industry solution for collision detection. Basically, it renders a second offscreen canvas of the map, and uses colors to define layers and shapes. I believe the red channel is used to define the layer ID (you can have up to 256 layers rendered in a single map view), while blue and green combinations were assigned to each shape, which meant you could have up to 65,536 shapes rendered within the displayable map view (shapes that weren't in view wouldn't need to be rendered, so the map could support loading and tracking a lot more shapes). When a mouse event occurred on the canvas, the color for the same pixel on the offscreen canvas would be retrieved and used to decode the layer and shape ID that was intersected. This made for high performance mouse interactions, with the main exception being around supporting right click on touch screens (long press). I recall us trying different wait times. I wanted little to no wait time, and although it might have been fine for some, it didn't align with accessibility guidelines and would have been a pain for a decent number of users. When we released it, this web SDK was the fastest one available for nearly 2 years. Eventually WebGL support grew enough, and the Azure Maps team went that route (You can try that one out here: https://samples.azuremaps.com/)

Answer 2

Hi Gary,

"Bing Maps" is a consumer product so there will not be a tag created here for that product. That product is supported at Answers.Microsoft.com > Bing > Maps. "Bing Maps for Enterprise" or API questions can be asked under either the "Windows-Maps" tag or "Azure-Maps" tags as it is the Microsoft Maps & Geospatial team that covers all Maps API questions.

As for the "JS" event on the Bing Maps V8 control, I will ask the team for their insights and get back to you here.

Sincerely,
IoTGirl

Answer 3

Hi @Gary_F ,

We have been unable to see the delay. Here are the steps that we used:

1. Open the iSDK and choose Getting started > Events > Polygon all events
2. Use the map, click, move etc
3. repeat with other browsers / Mobile devices

Result: No delay, worked as fast or faster than the built in app

I personally used multiple Android phones with multiple browsers and saw no delay. My assumption is the delaty is somewhere in your network of debug setup.

Sincerely,
IoTGirl

Answer 4

Hi @Gary_F ,

Did the Mouse Up work? There is obviously some architecture difference in what you are doing that we can't replicate here.

Sincerely,
IoTGirl