Small sectors in pie chart render incorrectly (Chrome / Linux)

[RoadrunnerWMC]

If a pie chart has a sector that is vanishingly small, the sector may be rendered with a completely incorrect position and size (not even concentric to the rest of the plot).

This seems to occur only on Chrome and Chromium (tested on versions 80.0.3987.149 and 80.0.3987.87, respectively). I'm running Linux (KDE Neon, which is Ubuntu-based), and could not reproduce this on Windows using Chrome or Firefox.

Demo

Expected result (shown here with Firefox):

Actual result when viewed in Chrome or Chromium on Linux:

[antoinerg]

I could also reproduce this issue in Chromium Version 80.0.3987.132 (Developer Build) (64-bit) on Linux. Thanks @RoadrunnerWMC for reporting this issue!

[alexcjohnson]

OK on Chrome on a Mac. Here's the markup I see for that slice:

<path
    class="surface"
    d="M144,150l-142.9672172205876,-17.21553949782922a144,144 0 0 1 1.3864902825844183e-7,-0.0000011514169706572375Z"
    style="pointer-events: all; stroke-width: 0; fill: rgb(95, 211, 95); fill-opacity: 1; stroke: rgb(68, 68, 68); stroke-opacity: 1;"
></path>

I'm curious if you see the same on Linux - particularly the d (path data) attribute.

If it's the same, that implies maybe exponential notation is broken in the SVG engine for Chrome on Linux?.

Two possible solutions:

1. ensure we're always using fixed-point decimal notation in constructing SVG attributes, see if that fixes it
2. maybe more robust: when the arc gets too small, switch to a line.

[RoadrunnerWMC]

Happy to help! And, the markup on my end (Chromium/Linux) is identical to that.

[alexcjohnson]

Thanks for checking the markup @RoadrunnerWMC - so the issue is definitely on the SVG rendering side, not on our data processing side.

I'd probably vote for the "switch to a line" solution, perhaps when the angle is <0.001 radian or something, that's negligibly nonlinear anyway. But also most places in plotly.js we round our path definitions to 0.01px, this is apparently an exception to that... at some point it may be worth hunting around all our trace types to do that everywhere.

[gvwilson]

Hi - we are trying to tidy up the stale issues and PRs in Plotly's public repositories so that we can focus on things that are still important to our community. Since this one has been sitting for several years, I'm going to close it; if it is still a concern, please add a comment letting us know what recent version of our software you've checked it with so that I can reopen it and add it to our backlog. Thanks for your help - @gvwilson

[RoadrunnerWMC]

I do still see this bug with Chrome 127.0.6533.119 on Linux (KDE Neon), and Plotly 2.34.0. It seems a different pie segment is triggering the bug now than four years ago, though.

JSFiddle updated to use Plotly 2.34.0

Markup for the "LLLLLL" slice:

<path
  class="surface"
  d="M144.5,150l-143.46363103013977,-17.27531683205607a144.5,144.5 0 0 1 2.782609271889669e-7,-0.000002310829891882804Z"
  style="pointer-events: all; fill: rgb(255, 181, 116); fill-opacity: 1; stroke-width: 0; stroke: rgb(68, 68, 68); stroke-opacity: 1;"
></path>

I don't see the bug anymore in Chromium 128.0.6613.84. I don't know if that's due to a difference between Chromium and Chrome, between v127 and v128, or the fact that I've switched to a different Chromium packager since opening this issue years ago, but I'd guess it's the first one.

---

Back when I opened this issue in 2020, I ultimately found that I could work around it in my case by setting a nonzero left margin in the layout, though I don't know why that made any difference. Since this issue still exists but no longer directly affects me, it's up to you whether you want to re-open it.

[archmoj]

I could confirm the bug in Chrome 128 on Ubuntu.