Box / lasso select don't visibly fade overlapping markers

[monfera]

In case of selecting an area, the markers ourside of the drawn area are faded. It's achieved by lowering glyph opacities. It works well in the special case when there isn't significant marker overlap. 2-3 overlapping transparent points however look like a single, fully opaque point as if inside the selection box.

Wondering about how best to solve it at some point as we have some more general issues pertaining crossfilter and other differential styling.

Example animgif explanation: first there's the current box select at work; then, upon release, the style is persisted with a crossfilter approach that's item 2 below.

Options, weaknesses:

1. Leave it as it is: above problem
2. Lower the opacity for the entire trace: then a new trace (or other mechanism) must draw salient points over the base layer, which requires runtime trace addition (traces up to this point, with the exception of the crossfilter, are fully in the user's control); convoluted in the presence of multiple traces; lines can't be done to general satisfaction
3. Break up the original trace(s) to pairs: retained and excluded sets; style them differently: it complicates the trace logic as it adds and removes traces on the go, also impacting the original trace
4. Superimpose an SVG mask over the area to be faded: the problem is, selection is based on mathematical points (eg. center of circular markers) but highlight / fade happens for the screenspace marker (ie. full circle). There may be partly overlapping circles, some of which fall inside the selection box/lasso, some of which don't.

Maybe it's been figured out or deemed unimportant, I'd be interested if it's a useful topic at all.

[rreusser]

1. …
2. seems very problematic to add and remove traces on the fly as a result of interactions, unless it's part of a more complete system like crossfilter where you can clearly 'commit' the result at the end of an interaction.
3. so probably augmenting the trace with a data array that applies this styling as part of traces/scatter/plot.js? Seems potentially tricky to get working flawlessly alongside all the other trace styling features.
4. Not a bad option. seems best to me, though seems like it would depend on whether the plot background is black/white/opaque/transparent in a way that requires the user to configure correctly.

I think leaving as is is probably okay for now, then option 4 would be next for me since it seems the most 'correct'. Right now it feels like somewhat of a corner case that markers exactly overlap each other. I think maybe a more common case would be that markers partially overlap each other so that it's somewhat less ambiguous, or at least that it at best just augments what's conveyed by the selection box, so that the above issue isn't ideal but also isn't fundamentally misleading.

Overall I'd put in the "either the simple way with option 4 or just very nice to have but adds a fair amount of complexity so that it's probably not worth addressing until it keeps showing up and becomes necessary to address" category.

[alexcjohnson]

Good point @monfera - I did notice this when putting together selections initially but ignored it. Perhaps it's time to revisit...

I really like the effect of a point popping on/off as it crosses the selection boundary - which would change to a slow fade in/out with a mask - both less appealing and less useful as you can't really tell which points will be included/excluded.

It's probably also worth mentioning that if there are a lot of traces, the trace opacity approach will fall down in the same way.

What if instead of changing opacity, we blend each deselected point with the background color, such that they all get the same color as a solo point does now, regardless of overlap?

[etpinard]

Maybe we should merge this ticket with #1847

[monfera]

Closing this ticket in favor of #1847