Replies: 1 comment 3 replies
-
Is there a reason you are not using the
That is not true. Only the pixel under the cursor is drawn and read. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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.
Long story short, Mapbox's
queryRenderedFeatures
is 10-30x faster than Deck'spickObjects
for this case. At least in my application, in which I usepickObject
in order to change the cursor state to show that someone's hovering over a grabbable feature, this shows up: a baseline forpickObject
is something like 10ms, rather than around 1ms for Mapbox's queryRenderedFeatures.The issue is that(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.pickObject
reads the whole canvas, for every call.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.
Beta Was this translation helpful? Give feedback.
All reactions