stacked histograms have different start/end values on hover

[nicolaskruchten]

https://codepen.io/nicolaskruchten/pen/BaNxYzM

This is weird:

[alexcjohnson]

FWIW this happens with regular split hover as well -

[alexcjohnson]

we are just doing the calculation of number of digits to show in these labels independently for each trace even when they're stacked or grouped so the coordinates should match.

[archmoj]

@alexcjohnson is this a bug?

[alexcjohnson]

Yes, bug. I forget how that calculation works but whatever it does should be shared by all traces in a group or stack.

[antoinerg]

The test added in ee1a6ba showcases the problem at hand.

The problem comes from the fact that each trace has its own rounding function roundFn which is determined by their trace specific leftGap and rightGap:

plotly.js/src/traces/histogram/calc.js

Lines 112 to 131 in 9a75ef0

	for(i = 0; i < pos0.length; i++) {
	var posi = pos0[i];
	n = Lib.findBin(posi, bins);
	if(n >= 0 && n < nMax) {
	total += binFunc(n, i, size, rawCounterData, counts);
	if(uniqueValsPerBin && inputPoints[n].length && posi !== pos0[inputPoints[n][0]]) {
	uniqueValsPerBin = false;
	}
	inputPoints[n].push(i);
	ptNumber2cdIndex[i] = n;
	leftGap = Math.min(leftGap, posi - binEdges[n]);
	rightGap = Math.min(rightGap, binEdges[n + 1] - posi);
	}
	}
	var roundFn;
	if(!uniqueValsPerBin) {
	roundFn = getBinSpanLabelRound(leftGap, rightGap, binEdges, pa, calendar);
	}

which then sets the hover values that end up being different:

plotly.js/src/traces/histogram/calc.js

Lines 176 to 177 in 9a75ef0

	cdi.ph0 = roundFn(binEdges[i]);
	cdi.ph1 = roundFn(binEdges[i + 1], true);

[antoinerg]

One possible solution is to defer the evaluation of ph0 and ph1 to after we're done with the calc phase of all traces. This is what is implemented in branch fix-4648. It's rather hacky but it seems to solve the issue at hand.

cc @alexcjohnson @archmoj can you have a look at it?

[alexcjohnson]

Ideally things like this belong in crossTraceCalc, though that could also be hacky since histogram shares that with bar. Your solution looks good, it's just better to minimize the work in hover when possible.

[antoinerg]

Ideally things like this belong in crossTraceCalc, though that could also be hacky since histogram shares that with bar.

I forgot that crossTraceCalc is executed after the calc steps of each trace. I could definitely do the work of computing ph0 and ph1 over there. The only downside is that we will have to loop over all the bars again.

Your solution looks good, it's just better to minimize the work in hover when possible.

I understand that we may not want to add latency to something interactive. Computing everything in advance is probably a better approach considering we don't usually have a lot of bars.

Thanks for the review @alexcjohnson