Freeze when setting dashed linewidth to a close-to-zero float · Issue #14498 · matplotlib/matplotlib · GitHub

Bug report

Bug summary

When setting the linewidth to a value close to zero (like 1e-15) and having a dashed linestyle in a pyplot, the application freezes.

Code for reproduction

from matplotlib import pyplot as plt

x = [0,1]
y = [0,1]

p = plt.plot(x,y, ls = "--", lw = 0.1, ms = 0.1, marker = "o", alpha = 1.0)

# ok
# plt.setp(p, lw = 1e-3)

# freeze
plt.setp(p, lw = 1e-15)

plt.show()

Actual outcome

The window opens but no plot (not even axis) is shown, instead the window is not responding.

Expected outcome

Primary Expectation: The application should not freeze.
Secondary Expectation: Show either no line at all or as thin as displayable.

Matplotlib version

Operating system: Windows 7
Matplotlib version: 2.2.4 (same with 3.1.0)
Matplotlib backend (print(matplotlib.get_backend())): TkAgg (same with Qt5Agg/PySide2)
Python version: 3.6.5 32bit

installed with pip

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.

I wonder if this is also partly dependent upon the figure's dpi setting? If so, then a straight-up clipping of 1e-2 is not sufficient as at high dpi, it might still be visible, perhaps?

…

On Sun, Jun 16, 2019 at 2:29 PM Tim Hoffmann ***@***.***> wrote: 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). - 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14498?email_source=notifications&email_token=AACHF6BJJGCDVS5OHJIIUZ3P22BCFA5CNFSM4HWHWOAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZSSAI#issuecomment-502475009>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACHF6F2HYCNWUADKPE33FTP22BCFANCNFSM4HWHWOAA> .

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

matplotlib/src/_backend_agg.h

Line 408 in db90685

linewidth = (linewidth < 0.5) ? 0.5 : mpl_round(linewidth);

so they do not suffer from the increased number of points for small widths and thus do not have a performance issue.

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?

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

Freeze when setting dashed linewidth to a close-to-zero float · Issue #14498 · matplotlib/matplotlib · GitHub

Repository navigation

Freeze when setting dashed linewidth to a close-to-zero float #14498

Bug report

What to do?

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Freeze when setting dashed linewidth to a close-to-zero float · Issue #14498 · matplotlib/matplotlib · GitHub

Repository navigation

Freeze when setting dashed linewidth to a close-to-zero float #14498

Description

Bug report

Activity

anntzer commented on Jun 10, 2019

timhoffm commented on Jun 16, 2019

What to do?

WeatherGod commented on Jun 17, 2019

timhoffm commented on Jun 17, 2019

tacaswell commented on Jul 7, 2019

timhoffm commented on Jul 7, 2019

ImportanceOfBeingErnest commented on Jul 7, 2019

timhoffm commented on Jul 8, 2019

jklymak commented on Jul 8, 2019

tacaswell commented on Jul 8, 2019

timhoffm commented on Jul 8, 2019

jklymak commented on Jul 8, 2019

4 remaining items

jwuphysics commented on Jun 26, 2020

oscargus commented on Mar 4, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions