Massive performance problems with drawing in IE 11 - > we created SVG overlay to get around it.

[janerivi]

mapbox-gl-js version:
0.28

Steps to Trigger Behavior

We initially developed a drawing module using the mapbox gl api and using sources and layers that we updated when we created or edited our drawings. This worked ok (not great) in Chrome (we had to use throttling). But when we ran the code in an IE11 browser the performance had massive problems.

Compared to the draw plugin for leaflet it was like two different universes where leaflet draw ran like a cheeta at 60fps and our implementation on top of the mapbox api took multiple seconds between each visible change.

But its not only our implementation that is badly written (even though there are many performance optimizations we probably should have done) we notice also that the mapboxgl example drawing plugin is also super sluggish on IE11:

https://www.mapbox.com/mapbox-gl-js/example/mapbox-gl-draw/

This sort of took away our hope of succeeding in overcoming the IE11 performance issue.

Just out of curiosity we tested the project function (from lat lng to screenpixel pos) and saw it could do a million projections in shorter time than a it took for one extra line or circle to appear on the map.

So we basically made an SVG layer covering the map and implemented our drawing module on the SVG and DOM api and hooked up to the map move event to perform projection on all the lat lng positions of our drawings to correspond with the current tilt, zomm rotate and translate of the map. Now we get the cheeta speed we are used to in the leaflet world back

But it seems like a stupid thing to have to do an SVG overlay in 2016 as a workaround to problems with the coolest vector map engine in the world.

Another major annoyance for our drawing plugin was the lack of outline/stroke options for polygons forcing us to have to make a duplicate layer just for the outline/stroke styles. The lack of such options are justified with performance arguements.

Suggestion:

Make arcitechture for a sort of "VIP layer" that is taylor made for dynamic 60fps editing or visualizing dynamic realtime data. I'm not sure if it is possible at the current state of the webplatform, but I know webgl games are starting to get more performant and they often involve lots of dynamic changes at 60 fps. Until then we will probably resort to stuff like SVG overlays.

Expected Behavior

Webgl cheeta superspeed.

Actual Behavior

The march of the sloth

[jaapster]

We are actually looking at OpenLayers 3 as an alternative because of this issue ...

[dannybloe]

Interesting.. we are moving away from mapbox-gl to OL3 exactly for those reasons too. It simply doesn't perform in Microsoft browsers and we can't just ignore them, unfortunately.

[jaapster]

I just found out that this issue is significantly exacerbated by #3398.
When we don't render raster layers in our app, drawing performance is much better in IE11.
The effect is also noticeable in Chrome.

[lucaswoj]

Thanks for the diagnosis @jaapster. I will tag #3398 as an important issue that needs to be addressed before the next release.

[jaapster]

Lacking performance in MS browsers when rapidly updating a geojson source's data is still a major obstacle for us. Yesterday I filed #4271 about jittery behavior when drawing in Firefox. Could that be related?

[eltonjuan]

@jaapster You have any luck fixing this? We are in the same boat -- we are updating geojson source data on hover (as a performance optimization when displaying large datasets) -- works great in chrome but in firefox it is laggy, flickering, etc. Makes the experience just about unusable.

[andrewharvey]

Further testing this on IE11, it seems to be worse on larger view ports. One effect is that as you edit a feature using GL Draw moving the mouse very fast the rendering lags behind.

This is triggered every time the cursor moves but often a backlog of these move events builds up, a quick fix here might be to cancel any rendering etc relating to the previous mouse event when a new mouse event comes in.

[andrewharvey]

Related to #3692 #2275 ...?

[anandthakker]

@andrewharvey Yeah, my instinct is that #3692 seems like the lowest-hanging fruit here

[Erutan409]

Has there been any traction on this? Currently caught off guard by how poor the performance is when I started testing my page with IE 11.

[eltonjuan]

Just an FYI, we ended up working around this using browser detection. If we detect an unstable browser (IE / Firefox) we provide a Leaflet version of our map instead of using Mapbox. If you'd like some sample code on how to do that just let me know.

[bart-1990]

We're also experiencing performance issues when drawing big linestrings in IE. Switching to Leaflet is not really something we'd happily do because we are very satisfied with all the features Mapbox has to offer. Is there any explanation why things are much slower in IE? Is it because of the js engine, because IE doen't support all WebGL specs, because of certain functions in the mapbox code that slow IE down? Any suggestions for improvements?

[ChrisLoer]

Is there any explanation why things are much slower in IE?

@bart-1990 It's always going to be case by case, but when we have serious performance problems specific to IE it's common that (1) the IE implementation differs significantly in behavior/performance from most other browsers, and (2) we don't notice the problem during development because none of us actually use IE (although we do explicitly test IE as part of each release, there are always use cases we'll miss).

We've addressed #3398 and #3692, which were sort of the "low hanging fruit" here. Also, regarding the original request for "webgl cheeta superspeed", we now have "custom layers" functionality that will allow you to draw directly to the webgl context instead of doing the expensive "draw via updating a geojson source" that runs into performance limitations (see https://www.mapbox.com/mapbox-gl-js/example/custom-style-layer/). It's a much lower-level way to do drawing, so it's definitely not the answer for every problem, but definitely could be useful for some of these cases. Also it broke in IE on our first release, but we think we fixed that! (#7406).

With those changes, I think it may make sense to close this issue, although we're definitely still interested in tracking IE performance issues. Could you create a JSFiddle showing the behavior you're seeing so that we can see if it's related to the GeoJSON source updating issue, or something else?

[ansis]

Closing because IE 11 is no longer supported.

This issue touches on general data update performance which might be an issue in other browsers as well. I think other issues such as #2275 cover those well enough.

Thanks for all the discussion!