Benchmarking picking versus an index approach

[tmcw]

Hi there! I've started to use Deck in my application a bit and it's great! I'm seeing a lot of spots where it's faster than what I was doing before. However, also seeing some spots where it's quite a lot slower. I wrote one up and created a quick benchmark to make sure I wasn't getting tricked by the chrome profiler.

• Repo: https://github.com/placemark/map-bench
• Deck.gl benchmark: https://placemark.github.io/map-bench/picking/deck.html
• Mapbox benchmark: https://placemark.github.io/map-bench/picking/mapbox.html

Long story short, Mapbox's queryRenderedFeatures is 10-30x faster than Deck's pickObjects for this case. At least in my application, in which I use pickObject in order to change the cursor state to show that someone's hovering over a grabbable feature, this shows up: a baseline for pickObject is something like 10ms, rather than around 1ms for Mapbox's queryRenderedFeatures.

The issue is that pickObject reads the whole canvas, for every call. (Corrected - it only reads the pixels under the cursor) This is a very slow operation. I suspect that it could reuse a previously-read value for the picking buffer if the map hasn't changed, but that's just a guess.

I'm also not sure whether there are advantages to the picking approach that I'm not seeing - versus an in-memory index, I'd guess that it's faster to write a picking buffer than it is to build an index, maybe - and maybe it's easier to implement a new layer type using picking rather than indexing. But, as-is, it's a bit tough to accept the performance hit from the alternative approach that relies on full-canvas reads.

[Pessimistress]

in my application, in which I use pickObject in order to change the cursor state to show that someone's hovering over a grabbable feature

Is there a reason you are not using the onHover callback?

pickObject reads the whole canvas

That is not true. Only the pixel under the cursor is drawn and read.

[tmcw]

Is there a reason you are not using the onHover callback?

In this case, mostly because I only want to know about one of the layers on the map, and as far as I can tell there's no way to get the equivalent of the layerIds option via onHover, but maybe there is?

Only the pixel under the cursor is drawn and read.

My mistake, that's right.

[Pessimistress]

But to answer your questions more generically: Mapbox builds a spatial index of the features on the CPU, while deck.gl queries features by drawing them into a framebuffer. The CPU <-> GPU round trip does come with a cost. The deck.gl approach is more efficient and accurate when you have frequently changing data with dynamic styling.

Generally speaking, I do not recommend calling the picking methods on pointer move. Pointer move events may occur more than once per animation frame (on which any layer update is applied) and as you observed, will force expensive operations unnecessarily. Deck's animation loop already performs one picking per animation frame for triggering the onHover/onClick callbacks, and you should tap into that as much as you can. Applications usually only require manual picking on click events, which is relatively less performance sensitive, if they need to query multiple overlapping features or the altitude of the pixel.

[Pessimistress]

mostly because I only want to know about one of the layers on the map

First, if a layer is not expected to be interactive, you should avoid setting pickable: true.
If you have layers that need to be pickable sometimes, a trick is to use the layerFilter callback:

layerFilter: ({layer, renderPass}) => {
    if (renderPass === 'picking:hover') {
        return layer.id === 'pickable-layer-on-hover';
    }
    return true;
}