Add option for rounded corners on bar charts

[emilykl]

Resolves #2196 😎

Description

Adds the option to round the corners of bar traces.

• Add property cornerradius to data.marker for bar traces
  • cornerradius may be either a numeric pixel value, or a string specifying a percentage of bar width
• Add property barcornerradius to layout, which sets default corner radius for all bar traces — easiest approach when all bars in all traces should have the same rounding
• When rounding is applied to a bar, rounding will also be automatically applied to the corners of its legend icon (if applicable)
• Stacked bars are treated as a single bar for the purpose of rounding, meaning that if radius is larger than the height of the top bar, rounding may extend to lower bars

Checklist

• Implement data.marker.cornerradius
  • Handle base case
  • Handle horizontal bars
  • Handle negative bars
  • Handle reversed axes
  • Handle stacked bars
  • Handle text position
  • Handle bars whose base is not at 0
• Implement layout.barcornerradius
• Implement rounding of legend icons
• Add image test
• Test with all existing bar plot mocks
• Add draftlogs/6761_add.md and mention the sponsor

Partnership

Development of this feature is sponsored by Displayr.

[archmoj]

plotly.js/src/traces/bar/style.js

Line 34 in 17f7013

d3.select(this).attr('shape-rendering', 'crispEdges');

Using shape-rendering: 'crispEdges' the rounded bars do not look great inside the browser.
I suggest we do not add it when there is a rounded bar that position.

[archmoj]

We only need these when having bars with rounded corners.
This function is pretty slow and it should not be called when it is not really needed.

[emilykl]

@archmoj Yes good point. Would it make sense then to check whether any of the traces in calcTraces have a cornerradius value, and skip this function if not?

[archmoj]

Yes that's a good idea.

[archmoj]

We shouldn't get into this if statement, if the value is presented in a string but not having a percentage at the end.
Also we may replace parseFloat by unary plus operator to get NaN when the remaining string is not a number.
Something like:

                } else if(typeof radiusParam === 'string' && radiusParam.slice(-1) === '%') {
                    // If radius is given as a percentage string, convert to number of pixels
                    var rPercent = Math.min(50, +radiusParam.slice(0, -1));

[alexcjohnson]

Better to use isNumeric to find if the value is a number, it's our standard method of finding either number type or numeric string:

if(!radiusParam) {
    return 0;
else if(isNumeric(radiusParam)) {
    rPx = +radiusParam;
else {
    var rPercent = ...
}

[emilykl]

If cornerradius value is invalid (e.g. string not ending in %) should we log an error message or just ignore?

[alexcjohnson]

Ignore if it’s invalid. Plotlyjs has a separate validation utility that will alert you if any attributes you provide were not accepted, but if you don’t explicitly call that our convention is to silently ignore invalid items.

[archmoj]

This one shouldn't be added to barpolar.

[alexcjohnson]

Using shape-rendering: 'crispEdges' the rounded bars do not look great inside the browser.
I suggest we do not add it when there is a rounded bar that position.

crispEdges needs to have the same value for all bars at least in a given subplot, and bars that are either stacked or grouped with no gap don't look good without crispEdges, an odd subpixel gap ends up being created. So within those constraints we could look for opportunities to disable it, but my hunch is we should just keep it enabled everywhere.

[emilykl]

@archmoj @alexcjohnson What I've done here is:

• Factor the existing fitsInside logic out into a separate function textFitsInsideBar()
• If the bar is not rounded, just call that function
• If the bar is rounded:
  • Imagine the bar is shaped like a rectangle with squares of side length r chopped out at each corner (so a chunky cross shape)
  • Then, the text can fit either in the "wide" direction or the "tall" direction (this is similar to the "wide text" and "tall text" cases for the text scaling)
  • Use the textFitsInsideBar function to check each of those cases. The text fits if either case is true.

It's a pretty rough approximation but seemed better than calling the scaleTextForRoundedBar function multiple times.

[archmoj]

Brilliant!
(( 🏆 💃 ))
(( 🎖️ 🏅 🥇 ))