Vector features won't draw in IE if features are very far outside the visible extent

[ahocevar]

According to  this thread, there are problems in Internet Explorer when zooming in very far on vector layers with a data extent much larger than the visible extent.

This can be avoided if only features inside the the visible extent are painted.

The drawback of this method is that this requires the bounds of each geometry to be calculated, which is very slow in IE.

Attached is a fix for lib/Renderer/Renderer.js. The patch also contains an example (tests/manual/vector-features-performance.html) which shows performance of this on the Firebug console, compared to the way things are done in trunk.

I would not recommend to put this into trunk. This issue can be avoided by using techniques like WFS (with a bbox strategy) to add vector features to a map, where only features for the visible extent are requested from the server.

[ahocevar]

Update: I created a new performance test with LinearRing geometries. Also, we can now see the difference between the first and subseqent render passes. The first will be slower because the bboxes of the geometries will be cached.

The results are promising, so I've changed my mind and think now that this should go into trunk:

Firefox 2 (Linux):

First run - feature bboxes will be cached
addFeatures: 136ms
Test with all features inside extent
addFeatures: 106ms
addFeaturesOld: 113ms
Test with some features outside extent
addFeatures: 52ms
addFeaturesOld: 87ms

Internet Explorer 7 (Linux, inside VirtualBox):

First run - feature bboxes will be cached
addFeatures: 8232ms
Test with all features inside extent
addFeatures: 8572ms
addFeaturesOld: 7851ms
Test with some features outside extent
addFeatures: 2233ms
addFeaturesOld: 5537ms

[elemoine]

Hi Andreas, thanks for your investigation on this bug and the performance tests. This is serious work! Looking at your patch, I've been wondering if the bounds calculation and intersection could go in VML.js since this is an IE-specific issue, I'm thinking of VML::setStyle. What you think?

[ahocevar]

Replying to elemoine:

Hi Andreas, thanks for your investigation on this bug and the performance tests. This is serious work! Looking at your patch, I've been wondering if the bounds calculation and intersection could go in VML.js since this is an IE-specific issue, I'm thinking of VML::setStyle. What you think?

VML::setStyle is too late to do that. But I created a new patch which overrides drawFeature in Renderer.VML.

As the performance test shows, this will increase performance on IE as soon as there is a certain amount of features outside the visible extent:

First run - feature bboxes will be cached
addFeatures: 9051ms
Test with all features inside extent
addFeatures: 9263ms
addFeaturesOld: 8552ms
Test with some features outside extent
addFeatures: 2534ms
addFeaturesOld: 7211ms

[ahocevar]

new version, now only affects the VML renderer

[elemoine]

Andreas, one thing: VML::drawFeature doesn't have the description of its parameters in the ND comments. With this, and if you confirm that the unit tests pass, I'm fine with the patch. Thanks.

[ahocevar]

(In [7546]) "Vector features won't draw in IE if features are very far outside the visible extent". r=elemoine (closes #1602)

[pgiraud]

I may be wrong but it seems like tests are breaking with this patch on IE6.

[ahocevar]

The failing of the tests for Handler.Path and Handler.Polygon is not related to this patch.

[pgiraud]

I'm still convinced that this is related to this patch. However, I'm leaving this ticket closed because this raised another problem. I'm opening a new ticket for that (#1623).

[pgiraud]

(In [7552]) handlers test are not reflecting the reality, we now simulate a click, move then click \n that way geometry bounds are cleared, and the tests don't fail in IE6 anymore (See #1602), r=ahocevar,crschmidt (Closes #1623)