I’ve defined a simple Panel application with a PyDeck map in this notebook and I’m noticing likely a 100-200 millisecond delay between the time I click on a geometry and the time the click state updates in the control panel. This is in contrast to Plotly where I notice the update appears to be nearly instantaneous. Is there any way to reduce this delay? I would love to have responsiveness equivalent to what I’m experienced with Plotly when embedded in a Panel application.
I can’t help with speeding things up, but do you have a short video demonstrating the delay. What I can say is when I click on the map anywhere the coordinates under click state appear to update on click. I’m not really feeling a delay in use so might be down to environment system maybe. Once I get screen recording software installed I’ll demo what I see on my system. Fairly clean environment, windows 10 using edge.
The cause can be so many things. Without a minimum, reproducible example it will be very hard to find the cause. Could you provide a minimum, reproducible example?
Let me think about how I might do that. The trick will be recording the time of the click visually somehow so that the delay is visible. I have one idea that might work - I’ll see if I can install a program to register the click with a visible marker in the screencast.
If the notebook I shared above is not showing any discernable lag for you and @carl, that is encouraging information in itself. Beyond sharing that notebook, if you have other ideas about getting to a minimum reproducible example, I’m all ears!
Yes I thought this too as soon as I mentioned I’ll record it too, what I done was installed OBS studio and got power toys from Microsoft GitHub as you can setup a dot when you click - I’ll upload recording tomorrow
I put the notebook up on Google Colab and am seeing a lag comparable to what I’m experiencing on my Macs. Here’s the link to the notebook: Google Colab
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
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!
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.
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
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.
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…
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.
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
