Also, cc @jkseppan since you worked on the Travis macOS build. Note that the code in #18184 that was reverted to used to work fine, but that was before the Travis changes.

Well it's not just CI, I can't get that test to pass at all on my system. What I'm seeing on my system is that the two images in that test are saved with two different DPI's. Here's the before image (Mac Preview says 100 dpi):

And here's the after (Mac Preview says 200 DPI):

I can get the test to pass by passing dpi=100 to the two calls to savefig() in the test. That doesn't feel like a fix, though--why would the DPI change in this code?

fig, ax = plt.subplots()
assert_equal(
    type(fig.canvas).__module__,
    "matplotlib.backends.backend_{}".format(backend))

ax.plot([0, 1], [2, 3])

timer = fig.canvas.new_timer(1.)  # Test that floats are cast to int as needed.
timer.add_callback(FigureCanvasBase.key_press_event, fig.canvas, "q")
# Trigger quitting upon draw.
fig.canvas.mpl_connect("draw_event", lambda event: timer.start())
fig.canvas.mpl_connect("close_event", print)

result = io.BytesIO()
fig.savefig(result, format='png')

plt.show()

# Ensure that the window is really closed.
plt.pause(0.5)

# Test that saving works after interactive window is closed, but the figure is
# not deleted.
result_after = io.BytesIO()
fig.savefig(result_after, format='png')

Here's the minimum reproducible case for getting the DPI change:

import matplotlib.pyplot as plt

fig, ax = plt.subplots()
fig.savefig('before.png')

plt.pause(0.5)  # Need for change in DPI; plt.show() also equivalent

fig.savefig('after.png')

So the issue is that the macosx backend assumes its device scale is 1.0 until it does a draw, then it knows it from the graphics context. Just need to plumb something in to allow it to know that from the start.

Hello! This is my first time contributing, I'd like to work on this issue. Is there anything I should do previously or some steps I need to follow? @QuLogic

I think @dopplershift is working on this in the above-linked PR; I don't know what the state of it is at this moment.

I've poked at it, but I don't have anything useful to share IIRC.

Can this be closed now we've migrated off Travis?

Well, @dopplershift could also reproduce the problem, but maybe it can be fixed by #21365?

I can reproduce the failure with mpl 3.4.3, but everything seems to work OK with the current 3.5rc and master even without that additional PR. Note that it does still work with that additional PR for me too. So, I think this issue can be closed and returned to the v3.5.0 milestone.

OK, we can close then.