Improve rendering precision on monitors to avoid glitches on gridlines, zerolines, axes, ticks and borders

When displaying Plotly charts on the monitor, straight orthogonal lines such as those on the chart grid, axes, ticks, box borders etc, which are supposed to look exactingly consistent, frequently are rendered visually non-uniform in respect to their thickness, and potentially blurry. These imperfections can be very conspicuous and make the charts look glitchy and indeed quite sloppy.

This problem has been reported quite a few times on Plotly community boards and elsewhere, with no solution offered so far, e.g.:

Inconsistent display of zeroline & grid
Gridwidth is not the same for all gridlines
How to make gridlines same thickness
Yaxis gridcolor and griswidth
Strange phenomena of x-axis and y-axis linewidth
Plotly: Some gridlines are thicker than others?

Upon investigation, I found that the issue here lies with the implementation of svg rendering mode shape-rendering: crispEdges which is specifically enforced in Plotly charts. I believe this glitch may not be observed on every monitor, every system and in every browser or notebook application, but it is far from infrequent and in fact I have it on all my Windows systems with relatively high DPI monitors where the screen scaling factor is set by the system or manually to any value different than an integer multiple of 100%, in Chrome-based browser such as Chrome and Edge and in VS Code notebooks.

The solution therefore is to change this mode to one that will not cause the described antialiasing artefact, and indeed when in a Dash app, applying a shape-rendering: geometricPrecision !important; (or shape-rendering: auto !important;) style to some or all svg shapes marked with .crisp style removes the glitch.

This solution however is somewhat cumbersome, hacky, and limited, because it requires a means of applying a css operation on DOM that is not available in a pure Plotly chart render outside of some web app platform such as Dash, and overriding a hard-coded styling feature with an obnoxious !important condition to boot.

I'm not sure I'm ready to question with zeal the developers' intention to force shape-rendering: crispEdges setting for monitor rendering of all shapes in Plotly charts over automatic or geometrically precise modes, but I'll leave a note that I didn't find any perceptible deterioration to Plotly 2D curves when replacing it with shape-rendering: geometricPrecision on my 2.5K 16" laptop monitor, and when instead setting it to auto (the default mode per svg specification), the renderer also seems to favor geometric precision because the result looks identical, pleasing and problem-free overall. It should be noted that geometricPrecision does not remove antialiasing completely, just makes it more geometrically precise.

But either way, straight orthogonal lines on a monitor simply do not need either antialiasing or advanced sharpening - they are readily as crisp as it comes. This is why the crispEdges adds nothing good to them and in some cases can be detrimental due to imperfections of the implementation.

So here is my request to please consider either changing the default svg rendering mode to shape-rendering: geometricPrecision for straight-line chart elements such as gridlines, zerolines, axes, ticks and borders (including and especially legend borders) or, better yet, implementing a setting in chart config options or trace definitions allowing a programmatic switch from the API between available shape-rendering modes (which are auto | optimizeSpeed | crispEdges | geometricPrecision, per specification).

Beginne damit, den SVG-Rendering-Pfad des Diagramms zu finden, der den Stil .crisp und shape-rendering: crispEdges anwendet; der Issue enthält keine Datei- oder Testnamen. Vergleiche die verfügbaren Rendering-Modi und ermittle, ob eine Änderung des Standardverhaltens oder ein API-/Konfigurationsschalter angemessen ist. Erledigt ist die Aufgabe, wenn orthogonale Diagrammelemente konsistent gerendert werden, ohne die gemeldeten Unschärfe- oder Dickenfehler.