2

I'm using Openlayers, Geoserver and noticed that IE is very very slow to display WFS layers. I haven't so many WFS features, about 300. Google base layer appears after 1 sec. but my two WFS layers need each from 10 to 20 seconds to display. With Chrome, it requires only 2 seconds.

I tried to disable style rules, events, no change. It's really a client issue, my cpu goes up to 50% for iexplore during features loading. I tried with IE8 and 9, with two differents pc, same results.

It seems that I'm not the only one. I can keep using Chrome but would be interested to share ideas

Olivier

12
  • did you profile it with the IE dev tools? What istakingthe lomgest? Mar 24, 2012 at 18:51
  • I suspect your features are too detailed. How many vertices do they have? 2 seconds on Chrome is an awful lot for just 300 features.
    – unicoletti
    Mar 24, 2012 at 20:09
  • unicoletti : It's a set of cables, most of them have only 3 to 5 vertices, a few dozens have up to 30. I have no problem waiting 2 sec, my problem is to wait more than 30 with IE. @Ragi I don't know how to do that. I tried with 'F12' tool, with some break point I saw that my javascript is done in an instant and after, I wait 30 seconds not knowing what is happening, just seeing the CPU at 50% for iexplore.
    – Olivier
    Mar 25, 2012 at 8:28
  • I tried again to remove everything and keep only my WFS layer with gmap. Same result. By the way, one can try openlayers.org/dev/examples/wfs-states.html. Even if this layer is very light, it possible to see that Chrome displays immediately when IE requires several seconds between gmap and WFS layer of states.
    – Olivier
    Mar 25, 2012 at 11:07
  • 1
    IE9 supports SVG renderer, so performance in this browser more better than in IE8 (SVG renderer is not supported in IE8). What renderer do you use? Make sure to set the doctype properly in your HTML document: <!DOCTYPE html> for using SVG in IE9.
    – drnextgis
    Mar 26, 2012 at 2:23

1 Answer 1

1

We are using OpenLayers 2.13.1 with the Dutch PDOK map implementation and were experiencing severe performance problems with WFS sources. I found a simple way to speed IE up by about a factor 2. It is still slow, but at least there is a significant improvement. Also it seems to use less CPU than before.

When profiling, I noticed that the most time is spent in the XMLHttpRequest.responseText property. Looking at the OpenLayers code, I saw that a version of https://code.google.com/p/xmlhttprequest/ is used. That class was intended to emulate XMLHttpRequest for Internet Explorer versions lacking a built-in XMLHttpRequest object. However, this should not be required in IE9 and newer, and Open Layers 2.x does not work properly in older IE versions. IE < 9 has become very uncommon anyway, even for the most convervative of our customers.

To make a long story short, here is how to speed up Open Layers 2 in IE:

  • Start with OpenLayers.debug.js (unminified code)
  • Look for the XMLHttpRequest.js code block
  • Replace the browser sniffing code at the start of the class by:

    var bGecko = !!window.controllers, bIE = false, bIE7 = false;

  • Look for occurences of the text "ActiveXObject". Ensurte that all code depending on this is not executed. E.g.,

    if (false /* window.ActiveXObject */) {

  • Finally, a fix is needed for a namespace problem in IE. Look for this function inside OpenLayers.Format.XML:

    write: function (node) {

  • Add this code just before the closing bracket of the function:

    if ("ActiveXObject" in window) // If IE is detected

    data = data.replace(new RegExp('xmlns:NS\d+="" NS\d+:', 'g'), '');

  • After testing the fix, re-minify the code for release, e.g., by using Microsoft's Ajax minifier.

The replace statement was always needed to get WFS to work in IE11 and Edge. After disabling the XMLHttpRequest emulation, the same applies to older IE versions as well.

[edit]In addition to the above, we should fully avoid accessing request.responseText in IE. With the built-in XMLHttpRequst object, responseXML should always be available and valid. In my test, the original code spent about 8000 ms in responseText and 600 ms in responseXML. Actually, we do not need responseText at all in WFS.

Additional changes:

  • In function fGetDocument(oRequest) remove all code related to sResponse, leave only oDocument
  • In function fSynchronizeValues(oRequest) set oRequest.responseText = '';
  • Replace var response = arcxml.parseResponse(request.responseText); by var response = arcxml.parseResponse(request);

With these changes, no more time is spent in responseText, while the time spent in responseXML does not increase. I have also tested WMS and WMTS layers, they still work as before. I've repeated all tests in firefox and chrome, dit not find side effects.

[/edit]

Hope this helps,

Berend

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.