Bug in calculateBarIndexPixels

[benmccann]

Context

@tchan originally reported this bug in #4814. There are two separate issues in his example, so I'm opening this bug to track the bar chart issue

Steps to Reproduce (for bugs)

Here's a fiddle: https://codepen.io/anon/pen/JrpVza

Expected Behavior

The data point for 2017-01-17 18:00:00 should be charted before the tick for 2017-01-18

Current Behavior

The data point for 2017-01-17 18:00:00 is charted next to the tick for 2017-01-19

Possible Solution

I believe the bug is in calculateBarIndexPixels. The 17th element (i.e. the one with index=16) has a fullBarSize of 265 pixels, which is why it is mis-positioned by hundreds of pixels.

It's very strange that the bars in this chart have different sizes. I don't understand the intended behavior here, but I don't think it's a good default. If you do a Google Image search for 'bar chart' then all the examples have all the bars being the same size. Different widths is extremely uncommon

[benmccann]

@nagix @simonbrunel any ideas? I believe you guys had some additional plans for the bar charts that never got finished. @nagix would you be able to send the remaining PRs for the next steps of your plan?

[etimberg]

I did some investigation. If you remove maxBarThickness then the center is correct for the size of the bar. However, it seems that calculateBarIndexPixels doesn't account for bar thickness being overridden by the settings when calculating the position.

[etimberg]

replacing the end of calculateBarIIndexPixels with

if (size === fullBarSize) {
  base -= leftCategorySize;
  base += fullBarSize * stackIndex;
  base += (fullBarSize - size) / 2;
} else {
  base += size * (stackIndex - 0.5);
}

improves things, however there is a chance that bars overlap. Also, the bars at the end are only half visible

[benmccann]

That looks way better!

[simonbrunel]

Looks like a bug, the bar "anchor" point should be the associated tick value, so when specifying an explicit bar thickness, the bar should be centered around that point. I don't think @etimberg solution really solves the issue but instead creates more problems, like you said it will generate overlaps when bars have different sizes. Maybe @nagix have a better idea why the bar is not centered around the expected time when a bar thickness is specified?

[simonbrunel]

We should target to fix that bug for 2.7.1, not change the default behavior.