Hi @diehl
Thx. I tried the notebook and my experience looks like the below.
Its hard for me to judge if there is a 100-200ms lag by just looking at this. Can you put some more words on how you measure the lag?
2 Likes
I don’t think I can really help here other than my thoughts on it. If not thinking about lag then perceptually the update happens with my ‘complete’ click. When looking closer there seems to be a slight delay from start of click but I can’t quantify it. Visibly I put a 250-300ms marker on the mouse, as Marc says difficult to judge.
One thought is when does the update occur, it seems to be more on click_finish or some type of short_click_length_ms than on_click type of update. It also doesn’t update with long click but I have zero idea on how it’s sensing or measuring the click if it even is. Other thought is it feels constant if I attempt to click quicker the update happens at same rate as a lazy click and not due to some random lag here and there. So my feelings lie with how the click is handled but I’m saying that without knowing enough. Also I don’t have a reference from plotly to compare against so I return back to my perception of seems to correspond with my click
1 Like
Hi @Marc
It all comes down to human perception. If memory serves, friction in a user experience becomes burdensome when the delay surpasses 200-250 ms. I built a simple Panel application some months ago that would take the click on a given geometry in a PyDeck map and retrieve attributes for the geometry to display. The frustrating element in the experience was this delay. I had no idea how to overcome it at the time and went off to explore other options within the Python ecosystem. Plotly is the only other option that might work but the mapping support pails in comparison to PyDeck. So I’m suitably motivated to find a way around this user friction.
I tried last night to instantiate a Plotly example with the Panel controls visible to give you and @carl an example of that performant experience. Sadly, for whatever reason, the Plotly example doesn’t work in Colab as it does on my Mac. The Panel controls don’t update on a click event. I’ll see if I can find another way to realize that to give you both a point of comparison. I noticed in one of the Panel Plotly examples the addition of the attribute jslink=True. I added that attribute to the PyDeck example and unfortunately didn’t see any change in behavior.
Maybe a screen capture of the experiences on my end with a visual representation of the click is a start. I’ll dig into it.
I managed to find a program to visually indicate the click event so here’s a telling video that represents what I’m experiencing with PyDeck.
Apparently new users here can’t upload attachments! Strange. Here’s a link that will allow you to download the screen recording I made. Hope this adds some clarity!
1 Like
I tried again on Colab to set up a Plotly example and this time I succeeded. This shows the performance I’m experiencing on my Mac. It’s very snappy in comparison to the PyDeck example.
Take a look at this notebook.
Hi @diehl,
I think you might already know this but if not will add what I’ve unearthed, so I’ve been digging about and for whatever reason completely missed or overlooked the throttle - putting the below you see the effect on the hover data in the control
map = pn.pane.DeckGL(r,sizing_mode='stretch_both',throttle = {'view': 20, 'hover': 20,'})
In the underlying code the throttle doesn’t seem to be associated to the click just view and hover, I’m also not at the stage I understand how it’s all linked, I can see throttle ='s in the following page https://panel.holoviz.org/_modules/panel/pane/deckgl.html but I don’t understand how it’s used but can see click_state doesn’t seem to be used here, maybe there is a default throttle somewhere else for this.
1 Like
Hi @carl,
I love that you are bringing this up! I too have wondered about the throttle and I naively thought I was changing it by editing it in the control panel. Changing the code in my notebook to what you shared, with throttle values of 20 ms, definitely increased the responsiveness for the view and hover updates. I went looking as well for a throttle value for the clicks and came up with nothing in my initial attempt.
I’ll sit with this some more and see if any new ideas pop for how to diagnose this further.
It would be great to find someone on the Panel team that understands how those click events stream back and what that potential source of delay might be.
@Marc, would love to hear your thoughts on all this whenever you get a chance…
FYI - I noticed just now the click state update delay is very evident in this Panel Deck.gl demo on the Panel website.
Tonight I got as far as finding where the click state is updated, but have not been able to decipher how the event handling is done and where the delay might be appearing.
1 Like
Hi @diehl,
The code reads to me that this might be a possible feature request here to add the on_click to the debounce so you have more fine grained control of the update click if desired. The data appears to pass quickly from front end to backend, so feels possible but don’t know with any certainty
Here’s some interesting info: diference in delay between onClick and onHover · Issue #3783 · visgl/deck.gl · GitHub
2 Likes
As you mention a difference between PyDeck og Panel Deck.gl pane one thing to check could be the versions of Deck.gl js.
Panel will be running on 8.6.7
The latest version of deckgl.js wich PyDeck might be using is 8.8.27. See deck.gl - npm (npmjs.com).
Don’t think that is the cause. But it could be.
1 Like
Thanks @maximlt for sharing this! This makes it sound like the issue might be with deck.gl as opposed to Panel. Wondering how to diagnose this…
Ok @Marc @carl @maximlt, we’re in the home stretch. @maximlt provided a critical puzzle piece. My intuition said to take a look at a DeckGL example for Panel using a JSON spec. In the spec, I saw where I could make the change to ‘controller’ to turn off the double click zoom as referenced in the GitHub issue @maximlt identified. And boom, it worked! The delay is gone. See this notebook on Colab for pre and post demonstrations of the click performance. Now the final question to chase down - how does one make the same assertion via PyDeck?
And there’s another question lingering in my mind - should Panel have this flag set to False as a default for DeckGL visualizations? I’m thinking yes.
1 Like
And here’s the final piece of the puzzle.
When constructing a PyDeck visualization in pure Python, a view object is required to set the controller.
view = pdk.View(type="MapView", controller={"doubleClickZoom": False})
Then the view object is added as a parameter when creating the Deck object.
r = pdk.Deck(
...
views=[view]
)
I have a working example now that is as performant as we expected possible. Thank you @Marc @carl and @maximlt for helping to make this happen! This is a huge win for me. Been wrestling with this off and on for over a year now.
2 Likes
Could you ask your question with a mimimum, reproducible example in a new post? 
Very happy we’ve managed to help you @diehl ! Could you please open an issue on Panel’s Github repository, so that maintainers can discuss about disabling the double click feature by default, or at least for them to have a way to track that this should be documented, as the slow down is indeed quite large otherwise.
1 Like
This is a sweet victory @maximlt - thank you again! It’s my pleasure to document the solution paths. As you requested, I’ve opened this Github issue to document how to resolve the click state update delay for both Deck.GL and PyDeck visualizations in Panel. I used the examples from the Panel documentation in the notebook to make it very easy to map the solution paths back to the code already present. Hope this helps!
1 Like