The broken_barh method appears to reproduce ranges inconsistently: given two durations, the larger one appears smaller, and in some cases even disappears.
Code for reproduction
# example 1fig, ax=plt.subplots()
# broken_barh(xranges, (ypos, height))ax.broken_barh([(-50, 0.02)], ("CPU 1", 0.5), align="center")
ax.broken_barh([(-50, 1e-12)], ("CPU 2", 0.5), align="center", color="tab:blue")
ax.broken_barh([(-50, 0.02)], ("CPU 3", 0.5), align="center", color="tab:blue")
ax.broken_barh([(50, 0.02)], ("CPU 4", 0.5), align="center")
ax.broken_barh([(50, 1e-12)], ("CPU 5", 0.5), align="center", color="tab:orange")
ax.broken_barh([(50, 0.02)], ("CPU 6", 0.5), align="center", color="tab:orange")
ax.set_xlim(-55, 55)
ax.invert_yaxis() # order the bars from top to bottomax.set_title("Not defining the color seems to cause a bar not to show up!")
plt.show()
# example 2fig, ax=plt.subplots()
# broken_barh(xranges, (ypos, height))ax.broken_barh([(-50, 0.2)], ("CPU 1", 0.5), align="center")
ax.broken_barh([(-50, 1e-12)], ("CPU 2", 0.5), align="center", color="tab:blue")
ax.broken_barh([(-50, 0.2)], ("CPU 3", 0.5), align="center", color="tab:blue")
ax.broken_barh([(50, 0.2)], ("CPU 4", 0.5), align="center")
ax.broken_barh([(50, 1e-12)], ("CPU 5", 0.5), align="center", color="tab:orange")
ax.broken_barh([(50, 0.2)], ("CPU 6", 0.5), align="center", color="tab:orange")
ax.set_xlim(-55, 55)
ax.invert_yaxis() # order the bars from top to bottomax.set_title("Not defining the color seems to affect how bars are shown!")
plt.show()
Actual outcome
Unlike in the example found on the website, not specifying a color seems to affect how bars are represented, from not drawing them to them having incoherent sizes.
Expected outcome
I would expect a given duration to be represented exactly with the same size, irrespective of the color.
Additional information
I only tried two colors.
For now, I have fixed this by defining the colors in every case.
I have been using matplotlib 3.11 and python 3.11.
This behavior follows from the technical implementation as PolyCollection. Each rectangle is a polygon in the collection. By default they have a facecolor, but not an edgecolor. Eaces that are less than a pixel are not rendered at all. Edge lines are always rendered. With the color argument you set both facecolor and edgecolor so that the edge line becomes visible. A bar with an edge line is wider than a bar without edge as the edge line is centered on the edge, and thus half the linewidth is "outside".
This is a bit unfortunate, but I don't think we can change behavior here. The only thing we can do is document this better.
Note that you can also set edgecolor="face" so that the edge becomes visible, but you don't have to specify a color explicitly.
Activity
timhoffm commented on Oct 20, 2026
This behavior follows from the technical implementation as PolyCollection. Each rectangle is a polygon in the collection. By default they have a facecolor, but not an edgecolor. Eaces that are less than a pixel are not rendered at all. Edge lines are always rendered. With the color argument you set both facecolor and edgecolor so that the edge line becomes visible. A bar with an edge line is wider than a bar without edge as the edge line is centered on the edge, and thus half the linewidth is "outside".
This is a bit unfortunate, but I don't think we can change behavior here. The only thing we can do is document this better.
Note that you can also set edgecolor="face" so that the edge becomes visible, but you don't have to specify a color explicitly.