Too many pickable layers problem

[alduleacristi]

Hi all,

I am using deck.gl to create a map by consuming data from a tile server in MVT format and I am bit stuck. I really need some help from someone with more experience.

Currently I have 10 layers but each layer generate 3 different sub layers because there are multiple shapes in the data and also I am representing some objects using Icons.

The problem is that occasionally, while interacting with the map, some objects from the map cannot be selected anymore.
They are visible but they cannot be interacted with.

The only thing that I can observe in the console is a Warning which says "Too many pickable layers, only picking the first 255".
Another thing that it's worthy to mention is that all the layers have the pickable property set to true because all the objects displayed on the map needs to be
selectable.

I tried to debug this problem furthermore and I observed that internally deck.gl creates around 300-500 layer objects based on the layers structure and on the tiles received
from the tile server. From those layers around a half are marked as ready to be "garbage collected".

I am using deck.gl 8.5.7 and mapbox-gl 1.13.0.

Is there any way to force the garbage collector to remove those layers?
Is there any way to fix this problem?

Thanks in advance for your help.

[Pessimistress]

The internal layer state ("garbage collected" etc) is not related to this issue. Only layers that are drawn to the screen count towards the picking limit.

There are a couple of ways you can work around the issue:

• Do not render multiple MVTLayers. Merge your dataset on the server and filter them in renderSubLayers
• In onHover/onClick, manually call pickObject with a selective set of layerIds.

@ibgreen @felixpalmer I've seen questions like these a few times now. It seems that using multiple MVT layers is not uncommon. While I do not recommend the practice due to performance concerns, it is not easy to implement a custom alternative, especially after the binary feature. Given that we know the bounding box of each layer, I think the best solution is to cull layers on the CPU more aggressively during picking. I can put up a proposal PR.

[felixpalmer]

A proposal PR sounds good. Would another option be to perform the picking in multiple passes when when we have more than 255 pickable layers?

[ibgreen]

The problem is obviously that we can't fit enough info in a 32 bit RGBA value.

We could get around that by rending picking buffer twice, first rendering layer index and then rendering layer color. That would allow 2^32 layers with 2^32 objects each.

The cost is that we need two renders and, probably worse, two synchronous texture read backs.

There are a couple of ways to optimize that:

• Use multiple render targets (works on WebGL2 and many WebGL1 devices) - eliminates the multiple renders
• Use texture that is 2x the height and render layer indexes in upper half and object indexes in lower half
• Use a deeper color format on WebGL2, such as RG32UI. - This would not fix the problem on WebGL1, but some reduced functionality on WebGL1 could be acceptable.

[Pessimistress]

@felixpalmer @ibgreen #6733

[ibgreen]

Noting that mobile devices tend to force close a tab if it exceeds a few hundred MB, so renderbuffer memory can significantly add to memory pressure and doubling the size of the renderbuffer may reduce headroom for mobile deck.gl apps.