fix(bar-race): fix lines glitch with sub-pixel optimization in animations #14679

[Ovilia]

Brief Information

This pull request is in the type of:

• bug fixing
• [] new feature
• others

What does this PR do?

Apache ECharts uses sub-pixel optimization on horizontal and vertical axes (including splitLines, ticks, and minorTicks) so that these lines should be drawn only at the positions like 10px, 10.5px, 11px for lines whose lineWidth is 1.

But for the case of bar-racing, this may cause the weried moving of split lines as reported in #14679 . So this PR disables sub-pixel optimization when in animation to solve the problem.

Fixed issues

#14679

Details

Before: What was the problem?

2022-07-26.14.59.10.mov

Pay attention to the red lines.

After: How does it behave after the fixing?

2022-07-26.15.00.34.mov

Document Info

One of the following should be checked.

• This PR doesn't relate to document changes
• The document should be updated later
• The document changes have been made in apache/echarts-doc#xxx

Misc

ZRender Changes

• This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

N.A.

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.

Document changes are required in this PR. Please also make a PR to apache/echarts-doc for document changes and update the issue id in the PR description. When the doc PR is merged, the maintainers will remove the PR: awaiting doc label.

[pissang]

I think we can turn it off
automatically instead of configuring it manually. Users still need a sharp line on the static image after animation finished

[Ovilia]

@pissang Do you mean to turn it off when series.realtimeSort is true or always turn off? It may not be easy to turn it off when series.realtimeSort is true because the subPixelOptimize is under axis and in the axis it cannot know about which series are using it.

[pissang]

I meant disable it during animation and enable it when animation is done.

[Ovilia]

@pissang I'm not quite sure about if it's proper to make a done callback for group animations. Please help review again.
Also, current implementation doesn't consider the case when axis doesn't have animation. Should I check axisModel to get if there is animation and call setGroupSubPixelOptimize if not? This feels a little strange to me so I would like to hear about your opinion first and then make a thorough test.

[pissang]

I'm not quite sure about if it's proper to make a done callback for group animations

A more general solution is using a doneCount flag to check if all animations are done. But the current solution also looks good to me because all animation will be finished at the same time.

Should I check axisModel to get if there is animation and call setGroupSubPixelOptimize if not

This is not necessary. groupTransition will still call the done callback when animation is set to false.

[pissang]

In general I will give +1 on this PR.

[Ovilia]

2022-08-04.15.46.59.mov

I found a small shaking of the axisLine when legend is toggled. Is this acceptable?

[pissang]

@Ovilia I think it will be better to fix it. Seems it's because the animation will still perform even if the axis lines are exactly the same. We can do a further check if the points of lines are changed and still set subPixelOptimize to true if they are not changed.

[Ovilia]

@pissang I added the logic so that done callback is called if old or new group doesn't exist in groupTransition. Should I also traverse and check if g1 and g2 are the same? If so, done should be called and return before further logic. One concern is, with zrender animation, if an element is set with the same attribute, the done is still called after the duration, rather than instantly. So I guess it's not a good idea to call done instantly in groupTransition.

Other way to fix this is before calling graphic.groupTransition, I first traverse the group to check if anything changes and call graphic.setGroupSubPixelOptimize(this._axisGroup, true) and skip graphic.groupTransition if the group doesn't change, right?

[pissang]

Sorry for the late reply.

Other way to fix this is before calling graphic.groupTransition, I first traverse the group to check if anything changes and call graphic.setGroupSubPixelOptimize(this._axisGroup, true) and skip graphic.groupTransition if the group doesn't change, right?

What I thought was this way. Because the logic to toggle the subPixelOptimize flag is outside of the groupTransition method. Whether to skip it should also not affect this method.

[echarts-bot]

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

[echarts-bot]

⚠️ MISSING DOCUMENT INFO: Please make sure one of the document options are checked in this PR's description. Search "Document Info" in the description of this PR. This should be done either by the author or the reviewers of the PR.