Dhevenddra commented on issue #21650:
URL: https://github.com/apache/echarts/issues/21650#issuecomment-5436509253
I dug into this one. The label z2 is not ignored, it is taken from the wrong
element, and the symptom depends on the order the markLines are declared in.
## Root cause
`doUpdateZ` in `src/util/graphic.ts` threads a running `maxZ2` through the
tree and lifts each label to `maxZ2 + 2`:
```ts
if (isGroup) {
const children = (el as Group).childrenRef();
for (let i = 0; i < children.length; i++) {
maxZ2 = mathMax(doUpdateZ(children[i], z, zlevel, maxZ2), maxZ2);
}
}
...
isFinite(maxZ2) && (label.z2 = maxZ2 + 2);
```
The accumulated `maxZ2` is passed *into* the next sibling's call, so once a
sibling with a high `z2` has been walked, every later sibling's label inherits
that value instead of its own. Each markLine is its own `Line` group, so two
markLines with different `z2` land in exactly this path.
## Measured
Two markLines, `z2: 100` labelled HIGH and `z2: 10` labelled LOW, reading
`z2` straight off the display list:
| declaration order | LOW label z2 | HIGH label z2 |
|---|---|---|
| HIGH first, then LOW | **102** (wrong, expected 12) | 102 |
| LOW first, then HIGH | 12 | 102 |
The lines themselves are always correct at 10 and 100. Only the labels are
affected, and only when the higher `z2` markLine is declared first. That
matches the screenshot in the report, and it is why this looks like "z2 has no
effect on the label".
## The part I would like your view on
Passing `-Infinity` into the child call instead of the accumulated `maxZ2`,
so each subtree computes its own maximum while the parent still folds the
result into its own label, fixes it:
```
without: {"HIGH":102,"LOW":102}
with: {"LOW":12,"HIGH":102}
```
The full Jest suite passes unchanged with that in place.
What stops me opening it as a PR is the FIXME directly above that parameter:
> Ideally all the labels should be above all the glyphs by default, e.g. in
graph, edge labels should be above node elements. Currently impl does not
guarantee that.
The sibling accumulation partially delivers that today, as a side effect.
Scoping `maxZ2` per subtree removes the side effect, so a label could end up
under a glyph drawn by a later sibling. `doUpdateZ` runs for every chart type,
and I cannot run the visual regression suite here to see what moves, including
the `marker-z-z2` marks that came in with #21117.
So: is per-subtree scoping the behaviour you want, and should the "labels
above glyphs" intent be handled separately, or would you rather this were fixed
inside the marker code and left alone? Happy to open the PR either way once you
have pointed at the approach.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
