Repository navigation
addTraces upon plotly_selected event with scattergl not rendering correctly #2298
Description
https://codepen.io/cpsievert/pen/MrMMvj
Brush the blue marker. A red marker should appear at (1, 2), but it seems to be transparent.
cc @dfcreative
Activity
Add #2298 test
dy commentedon Feb 1, 2018
@etpinard
scattermode adds a new trace withoutselectedpointsset on it. Ie. new trace looks like as if its points are selected, but in fact it has no selection. Is that desired behavior? Or we better off showing new traces with all poins inunselectedmode?etpinard commentedon Feb 1, 2018
What does the svg
scatterimplementation do in this case?dy commentedon Feb 1, 2018
Should be fixed with #2311
cpsievert commentedon Feb 13, 2018
I modified the example slightly so the red marker should be placed directly on top of the blue marker, but again, the red marker isn't rendered.
May seem like a silly bug, but I need this fixed before I can update the R package...
dy commentedon Feb 14, 2018
@cpsievert #2367 fixes that.
It swaps canvas order.
The initial guess was that selected points are rendered as the top layer over the not selected ones. That may break cases where selected points overlap not selected ones.
Ultimately we have to choose one way or another. Selected points are a separate layer, we cannot mix them into main points layer to make per-point layering, since that will significantly reduce performance.
etpinard commentedon Feb 15, 2018
I prefer the behavior on
masterwith the selected points on top.@cpsievert here's one way to ensure that the red marker (from the new trace added by
addTraces) appears above the blue marker: https://codepen.io/etpinard/pen/VQMOOd?editors=0010cpsievert commentedon Feb 20, 2018
@etpinard populating
selectedpointsin that way will require some non-trivial changes on my end -- I imagine it should only be necessary forscattergl, though?etpinard commentedon Feb 20, 2018
yes.
chriddyp commentedon Mar 5, 2018
Looks like this is actually the issue to #2433 and https://community.plot.ly/t/webgl-context-lost-after-updating-10-times/8581/8?u=chriddyp. However, we're using
Plotly.reactrather thanPlotly.newTrace.In Dash, we were recommending that users replot their data after selection to customize selection styles. This no longer works since the second trace (with identical points as the first trace) now appears below the first trace that was originally plotted and selected. Here is a simple example: https://codepen.io/chriddyp/pen/YebmJL?editors=1010. Selecting the point used to display the second trace with the orange point on it, now it persists the first trace on top of it.
I can't necessarily use the
addTracesmethod since Dash users always pass in full figures and I just callPlotly.reacton them. I can promoteselectedstyles for the traces and attributes that support them. The documentation has some examples using a second trace for styling with properties that aren't available under theselectedkey (likemode). This is a breaking change for Dash so if we're going to keep the current behaviour I'll bump up the major version ofdash-core-components.cpsievert commentedon Mar 21, 2018
One way to work around this issue would be to "turn off" the selected/unselected api when a relevant event is triggered. More specifically, I'm thinking on a
plotly_selectedevent, I could do this:before adding a trace. However, it seems
scattergldoesn't understand this restyle call. Note how in this (similar) code pen, the opacity of the unselected markers remained dimmed forscattergl, but are (correctly) not dimmed forscatter-- https://codepen.io/cpsievert/pen/GxmWKaHappy to open another issue about
scatterglrespectingPlotly.restyle(gd, {"selectedpoints": null})etpinard commentedon Mar 22, 2018
Thanks for the report @cpsievert
selectedpointsseems to work fine innewPlot, but fails onrestyleand friends (example). I'll try to get a fix for this out today.merges commentedon Apr 3, 2018
Thanks for your work on this issue. Do you happen to have an idea of when the fix will be released?
jackparmer commentedon Sep 10, 2020
This issue has been tagged with
NEEDS SPON$ORA community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $10k-$15k
What Sponsorship includes:
Please include the link to this issue when contacting us to discuss.
gvwilson commentedon Jun 11, 2024
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson