You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've run into a problem drawing plots with dashed or dotted lines that extend out to many times the size of the plot area. This SSCCE demonstrates the issue on my system:
I instrumented this with a bit of timing code and found that the call to plt.show() takes about 13 seconds on my machine, during which the Python process is using 100% CPU. Playing with the values shows that the time taken by show() seems to be asymptotically linear in line_ymax / plot_ymax. Changing the line style to 'dashed' reduces the time by a factor of 2.5-3, while changing it to 'solid' makes the problem go away entirely. (I suppose this suggests something may be linear in the number of separate line segments being drawn.)
I also ran the code with line tracing enabled (python -m trace -t hang-mwe.py) and identified the specific line that hangs (or at least, the last line to be printed before the trace output pauses):
path.py(260): return self._simplify_threshold
A larger context from this run is attached in trace.txt, in case it helps; look around line 421.
The problem does not occur in the webagg backend. I also tried swapping in other backends (agg, cairo, pdf, pgf, ps, svg, template - all the options that didn't give an error) for good measure, but none of them displayed anything (though neither did they have any noticeable "hang time").
I found the issue on OS X El Capitan using Matplotlib 1.5.1rc1 and Python 3.4.4, both installed through MacPorts. It goes back at least as far as 1.4.0 (the earliest version I could compile) and is still present in the current master branch (196f344).
The text was updated successfully, but these errors were encountered:
OK, sorry, that didn't show up in my searches because I was looking for issues related to line styles, and to rendering of elements that don't appear in the final plot.
I tested on a Linux machine and couldn't reproduce the issue with any of the available interactive backends (GTK3Cairo, WebAgg, Qt4Agg).
I don't have another backend available on the Mac, but I'll see if I can install one.
efiring
changed the title
MacOSX backend hangs drawing lines with many dashes/dots
MacOSX backend hangs drawing lines with many dashes/dots
Mar 21, 2016
QuLogic
modified the milestones:
2.0 (style change major release),
unassignedMar 28, 2016
I've run into a problem drawing plots with dashed or dotted lines that extend out to many times the size of the plot area. This SSCCE demonstrates the issue on my system:
I instrumented this with a bit of timing code and found that the call to
plt.show()
takes about 13 seconds on my machine, during which the Python process is using 100% CPU. Playing with the values shows that the time taken byshow()
seems to be asymptotically linear inline_ymax / plot_ymax
. Changing the line style to'dashed'
reduces the time by a factor of 2.5-3, while changing it to'solid'
makes the problem go away entirely. (I suppose this suggests something may be linear in the number of separate line segments being drawn.)I also ran the code with line tracing enabled (
python -m trace -t hang-mwe.py
) and identified the specific line that hangs (or at least, the last line to be printed before the trace output pauses):A larger context from this run is attached in trace.txt, in case it helps; look around line 421.
The problem does not occur in the webagg backend. I also tried swapping in other backends (agg, cairo, pdf, pgf, ps, svg, template - all the options that didn't give an error) for good measure, but none of them displayed anything (though neither did they have any noticeable "hang time").
I found the issue on OS X El Capitan using Matplotlib 1.5.1rc1 and Python 3.4.4, both installed through MacPorts. It goes back at least as far as 1.4.0 (the earliest version I could compile) and is still present in the current master branch (196f344).
The text was updated successfully, but these errors were encountered: