queryRenderFeatures continued [not ready] #2224

The combined running time of placeCollisionFeature and insertCollisionFeature is now 2/3rds of what it used to be. The grid index divids a square into n x n cells. When a bbox is inserted, it is added to the array of every cell it intersects. When querying, look in all the cells that intersect the query box and then compare all the individual bboxes contained in that cell against the query box. This kind of index is faster in this specific case because it's characteristics better match the work we're using it for. Queries can take 1.3x as long (slower) with the grid index. But insertions often take < 0.1x as long with the grid index. Our collision detection code does a lot of insertions so this is a worthwhile tradeoff. The grid index also takes advantage of the fact that label boxes are fairly evenly sized and evenly distributed. The grid index can also be serialized to an ArrayBuffer. The ArrayBuffer version can be queried without deserializing all the individual objects first. This is not currently used.

This reduces the long-term memory usage of a tile by ~500KB. Saving memory is significant because it lets us cache more parsed tiles. This also speeds up CollisionFeature creation by about 60%. It's hard to measure, but this probably saves us a bit of gc time. Using an ArrayBuffer to store the data makes it potentially transferrable, which moves us closer to eliminating worker state. --- This also adds StructArray, a pretty fast and convenient way of adding conceptual objects to ArrayBuffers. var BoxArray = createStructArrayType([ { type: 'Int16', name: 'x1' }, { type: 'Int16', name: 'y1' }, { type: 'Int16', name: 'x2' }, { type: 'Int16', name: 'y2' }, { type: 'Float32', name: 'scale' }, ]); var boxes = new BoxArray(); boxes.emplaceBack(-2, -1, 2, 1, 1.23); boxes.emplaceBack(-3, -1, 3, 1, 1.23); var box = boxes.at(0); assert(box.x2 - box.x1 === 4); box._setIndex(1); // avoid creating a new box object assert(box.x2 - box.x1 === 6); How fast is it compared to regular objects? Adding features with emplaceBack is faster. Accessing and setting individual components is a tiny bit slower.

Why? Both indexes have comparable querying performance and Grid is transferrable. Insertion is faster with Grid than rbush but that's not the main benefit. Point queries are really fast for both. Each is sometimes faster than the other. Therre is no clear winner. Large, full-screen bbox queries are 10% slower with Grid than rbush but difference is not significant (0.2% of FeatureTree.query). comparisons were done with mapbox-streets-v6

- it's fast - this helps avoid worker postMessage clone costs - this prevents busy workers from delaying the results - this is a step towards lazily constructing GeoJSON and eliminating `includeGeometry`

This improves performance for large multipolygons and multilines. mapbox-streets-v7 collects features with identical properties and combines into a single giant feature. This saves space and speeds up parsing but it also makes indexing by feature bbox useless.

The code for converting to geojson is copied from https://github.com/mapbox/vector-tile-js 0f73eb2c417979601be973e046e169c74147ca7

It's much faster to deserialize straight from pbf than to deserialize and reserialize as GeoJSON. This also lets us lazily load geometries to make it even faster for cases where not all geometries are used. benchmark with buildings in mapbox-streets-v7 old (with stringify added) 85ms new 1.5 ms new with all geometries loaded 15ms benchmark with buildings in mapbox-streets-v6 old 500ms old (with stringify added) 150ms new 3ms new with all geometries loaded 15ms

Despite being potentially parallelized, this often takes longer than the synchronous verion because the features have to be parsed from the pbf twice instead of once. The advantage of the async version is that it spends less time in the main thread which can keep the everything more responsive. It still takes some time to parse all the features from the vector tile into geojson (~15ms for a full screen query in a dense area). Parsing the pbf on the main thread is faster than parsing json. Parsing the pbf on the main thread also lets us lazily load the geometry and avoid implementing the `includeGeometry` option.

for when polygon is just a point.

This significantly reduces memory usage for CollisionTiles that aren't used, or are barely used.

remove all FeatureTree tests. FeatureTree is covered by the query render tests. It's really hard to construct and verify test cases without visual help. Whenever the FeatureTree tests break its hard to tell if its a broken test or a broken implementation. It's way easier to create good query tests.

and accept only an array of strings. fix #2230

It's faster, but not fast enough to be worth it.

let's try to get by with just queryRenderedFeatures

and split intersection tests into a separate file

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

queryRenderFeatures continued [not ready] #2224

queryRenderFeatures continued [not ready] #2224

Commits on Mar 24, 2016