fix(splitLine): fix chart throws errors when splitLine is enabled in radius axis.

[plainheart]

Brief Information

This pull request is in the type of:

• bug fixing
• new feature
• others

What does this PR do?

The chart throws errors when splitLine is enabled in the radius axis, resolves #16731.

Fixed issues

• [Bug]极坐标柱状图半径多次改变后报错 #16731

Details

Before: What was the problem?

It will throw illegal argument errors as zrender basic shape Circle doesn't handle the value less than 0, unlike the Sector shape, it normalizes such an unexpected radius value.

After: How is it fixed in this PR?

Ensure the circle radius is non-negative in ECharts.

Comparison

Misc

• The API has been changed (apache/echarts-doc#xxx).
• This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

Please refer to test/splitLine.html

Others

Merging options

• Please squash the commits into a single one when merging.

Other information

[echarts-bot]

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

The pull request is marked to be PR: author is committer because you are a committer of this project.

[echarts-bot]

Congratulations! Your PR has been merged. Thanks for your contribution! 👍

[jiawulin001]

@plainheart @pissang Hi, good to see you've found a solution. Actually I have another thought about where the real problem is. At:

echarts/src/coord/Axis.ts

Lines 311 to 313 in ad3a07a

	each(ticksCoords, function (ticksItem) {
	ticksItem.coord -= shift / 2;
	});

The statement is dealing with tickItem.coord without judging the sign of it. In the case of radius axis, ticksItem.coord is equal to shift/2, but a very tiny error is introduced by binary storage when executing tickItem.coord -= shift/2. This makes ticksItem.coord a negative value when the error is negative, and BOOM, the painter won't accept a negative radius. This is why #16731 is happening.
The current solution only makes sure tickCoords.coord is positive when creating a new circle at:

echarts/src/component/axis/RadiusAxisView.ts

Lines 115 to 122 in c2f4ac6

	splitLines[colorIndex].push(new graphic.Circle({
	shape: {
	cx: polar.cx,
	cy: polar.cy,
	// ensure circle radius >= 0
	r: Math.max(ticksCoords[i].coord, 0)
	}
	}));

But there are other places where tickCoords.coord is used like:

echarts/src/component/axis/RadiusAxisView.ts

Line 182 in c2f4ac6

let prevRadius = ticksCoords[0].coord;

echarts/src/component/axis/RadiusAxisView.ts

Lines 186 to 194 in c2f4ac6

	splitAreas[colorIndex].push(new graphic.Sector({
	shape: {
	cx: polar.cx,
	cy: polar.cy,
	r0: prevRadius,
	r: ticksCoords[i].coord,
	startAngle: 0,
	endAngle: Math.PI * 2
	},

echarts/src/component/axis/RadiusAxisView.ts

Line 197 in c2f4ac6

prevRadius = ticksCoords[i].coord;

This can cause the same problem in the future.

So my suggestion would be:
Adding the one line in current PR is not enough, but instead a line should be added to

echarts/src/coord/Axis.ts

Lines 311 to 313 in ad3a07a

	each(ticksCoords, function (ticksItem) {
	ticksItem.coord -= shift / 2;
	});

and makes it look like:

        each(ticksCoords, function (ticksItem) {
            ticksItem.coord -= shift / 2;
            ticksItem.coord = Math.max(ticksItem.coord, 0)
        });

Please tell me if I got anything wrong or unclear.

[plainheart]

@jiawulin001 So much thanks for your deep dig. I've mentioned a bit in the MR description what you are concerned about [1]. That's why I didn't apply the changes to other places.

[1]

It will throw illegal argument errors as zrender basic shape Circle doesn't handle the value less than 0, unlike the Sector shape, it normalizes such an unexpected radius value.

• https://github.com/ecomfe/zrender/blob/master/src/graphic/helper/roundSector.ts#L126-L127
• https://github.com/ecomfe/zrender/blob/master/src/graphic/shape/Circle.ts#L32

[jiawulin001]

@plainheart Thanks for your explanation! Literally a lesson to me.