Improve polygons #594
Improve polygons #594
Conversation
Add a polygon example.
Speed up gl polygons a large amount. Before, the set of polygons in the example was taking between 240 and 350 ms to regenerate. The variability was largely caused by garbage collection. There were many slow points in our processing (earcut only accounts for 35 ms of this time). Now, much less memory is allocated and deallocated, and some maps have been unrolled to plain functions. The full generation time is around 60 to 75 ms, with much lower memory turn-over. Further, if only the style changes, the geometry doesn't need to be recomputed, so just recalculating styles takes 11 ms or so.
Sped up the pointInPolygon function, dropping its time (using the example data) from 10 ms to 2 ms or so.
When mousing over a polygon, these changes mean that it feels 'real-time' instead of very laggy.
Polygons had to be defined as {outer: [(points)], inner: [[(points)], ...]}, with inner being optional. Now, they can also be defined as [(points)], skipping the container structure, which is the same as {outer: [(points)]}.
Improved the documentation on polygonFeature.
Added a style called 'uniformPolygon', evaluated per polygon. If true, the fill color and opacity is only evaluated once for that polygon instead of once per triangle vertex. Only recompute the polygon triangulation and geometry if necessary. If only styles have changed, only styles are updated. Styles on uniform polygons aren't updated if they don't change. Styles are only computed once if they are not functions. Only recompute polygon style and geometry at most once per gl render cycle. The gl render call always moves to the end of the animation callback list to ensure that other calls can happen first. Unroll more maps into loops for speed. Don't remove and re-add the vgl actor on every update. Compute a bounding box for each polygon for faster pointInPolygon checking.
Current coverage is 78.82%@@ master #594 diff @@
==========================================
Files 82 82
Lines 7274 7354 +80
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 5560 5797 +237
+ Misses 1714 1557 -157
Partials 0 0
|
|
Some performance comparisons (all times in milliseconds) using world-wide 10 arcminute bathymetric data with 5779 polygons with lots of holes that convert to 2,209,058 triangles (6,627,174 vertices) from a 51 Mb json file.
The speed improvements come from changing map functions to loops, only calculating triangles as needed, calculating bounding boxes of polygons, and taking advantage of uniform values. Furthermore, createGlPolygons could be called multiple times per render in the before condition (almost always at least twice), whereas it is only called once in the new code. Now, the bulk of the update time is in the actual gl rendering (in bufferData). |
this is cool. For the point search, the speed up is because of the use of bbox? |
| opacity = fillOpacityFunc(vertices[0], 0, item, itemIndex); | ||
| } | ||
| } | ||
| if (uniform && onlyStyle && items[k].uniform && items[k].color && color.r === items[k].color.r && color.g === items[k].color.g && color.b === items[k].color.b && opacity === items[k].opacity) { |
There was a problem hiding this comment.
nit pick: can we wrap this long line/
|
It is also changing from the forEach to a loop, and not bothering to check On Mon, Jun 20, 2016 at 10:45 AM, Aashish Chaudhary <
David Manthey |
|
LGTM 👍 |
Add a polygon example.
Speed up gl polygons a large amount. Before, the set of polygons in the example was taking between 240 and 350 ms to regenerate. The variability was largely caused by garbage collection. There were many slow points in our processing (earcut only accounts for 35 ms of this time). Now, much less memory is allocated and deallocated, and some maps have been unrolled to plain functions. The full generation time is around 60 to 75 ms, with much lower memory turn-over. Further, if only the style changes, the geometry doesn't need to be recomputed, so just recalculating styles takes 11 ms or so.
Sped up the
pointInPolygonfunction, dropping its time (using the example data) from 10 ms to 2 ms or so.When mousing over a polygon, these changes mean that it feels 'real-time' instead of very laggy.
Polygons had to be defined as {outer: [(points)], inner: [[(points)], ...]}, with inner being optional. Now, they can also be defined as [(points)], skipping the container structure, which is the same as {outer: [(points)]}.
Improved the documentation on polygonFeature.
Note that this is dependent on PR #590, as the example uses that. It could be separated if necessary.