Looks like something wrong with Agg... Likely we should investigate the lowest value Agg can draw properly and clip linewidths in the backend_agg graphicscontext?

Turns out, small linewidths require a lot of computation. When running the above code with different linewidths, the plot window appears, but is black for a certian time. During that time CPU usage is at 100%. Computation time goes up very strongly when reducing the linewidth:

lw=1e-4   # ~1s
lw=1e-5   # ~6s
lw=1e-6   # ~54s

Further notes:

• the delay is caused by antialiasing (setting rcParams['lines.antialiased'] = False results in immediate draw).
  Edit: Just saw that without antialiasing, the linewidth is already clipped (_backend_agg.h ll.407):

          if (!gc.isaa) {
            linewidth = (linewidth < 0.5) ? 0.5 : mpl_round(linewidth);
        }
  

• resizing the plot also lags for small linewidths.
• with lw=1e-3 the initial draw is not noticably slower, however, resizing already feels a bit laggy.
• for values lw=1e-2 and smaller, no visible line is drawn at all.

What to do?

From a practical point of view everything equal or smaller than lw=1e-2 is identical (not drawn). I also don't think there are practical purposes for lines smaller than 1e-2 points. It should therefore be safe to clip lw to 1e-2.

Even 1e-3 is not sufficient for our test cases. See #14560. Needs more investigation.

Why are thin lines computationally expensive?

It seems to have to do with antialiasing. But not an expert in the field, I neither know what type of antialiasing agg is using, nor how thin lines affect the performance of antialiasing.

Why are thin lines computationally expensive?

I don't think thin lines are per se computationally more expensive than thick lines; it's just that dashed lines have more dashes the smaller their width. I.e. the number of dashes per unit length, and hence the number of points the renderer needs to draw, grows because there is a fixed dash-length to width ratio.

@ImportanceOfBeingErnest 👍 That explains it. Non-antialiased lines are clipped to a width >= 0.5

So can we just clip the dash length?

Sigh, the dash scaling is one of those rabbit holes with a 🐲 at the bottom.

We talked about clipping that scaling, but decided not to due to concerns about negatively affecting hi-dpi outputs.

attn @dopplershift as I recall you were the most vocal on not clipping the dash scaling in the run up to 2.0.

Adding an additional safety factor of 2 or 4 for hi-dpi should be enough, I mean how high can hi-dpi be compared to a standard resolution? If you are really concerned still, one could make that cutoff configurable, either in rcParams or in some global variable. That way users with extreme needs would still be able to draw any dashing correctly.

I agree. How high can hi dpi go? Are there really practical uses to 10,000 dpi?

So lw=1e-2 means you need to be running 7200 dpi to see that line. I think its fair to clip at 1e-2 and let the world know that Matplotlib doesn’t support higher dpi than this. Note that no fonts can be smaller than 1 point already due to the font rendering library limits, so its really hard to see why anyone would need a 1-point lettering and lines that are 100 times thinner than the font size.

So the original issue where I was arguing against clipping was #8032. The crux of my argument back then was that dots need to be dots, and we need to make sure we keep high DPI use cases in mind.

I'm not sure where lw=1e-4 comes into practice, but If we can solve this performance issue with even a rough clip at 1e-2 (and that indeed doesn't make a difference until you're higher than 7200 dpi), then I suppose that would be ok.

I get a similar freeze when trying to set dashes=(0, 0), e.g.,

plt.plot([0, 1], [0, 1], dashes=(0, 0))
plt.show()

I first encountered it in the Jupyter notebook environment and then replicated it in IPython. The window becomes unresponsive and my laptop fans kick in so I had to end the process.

I am using Python 3.7.3, matplotlib 3.1.1, Qt5Agg backend, and Linux Mint 19.1.

I get a similar freeze when trying to set dashes=(0, 0)

This part is fixed with #22569