What prevents a figure showing before notebook cell completion?

My issue boils down to:

“Why does the figure not show immediately, but instead waits until the cell has completed running?”

%matplotlib widget
import matplotlib.pyplot as plt
from time import sleep
fig = plt.figure()
plt.plot([1,2,3])
sleep(2)

This behaviour is preventing fun uses, like dynamic plotting in a single cell:

%matplotlib widget
from matplotlib import pyplot as plt
from time import sleep
import numpy as np
fig = plt.figure()

for i in range(10):
    x, y = np.random.random(2)
    plt.scatter(x, y)
    fig.canvas.draw()
    sleep(0.1)

The previous code works if one splits it into two cells, placing the figure() call in the first one:

# Cell 1
%matplotlib widget
from matplotlib import pyplot as plt
from time import sleep
import numpy as np
fig = plt.figure()

# Cell 2
for i in range(10):
    x, y = np.random.random(2)
    plt.scatter(x, y)
    fig.canvas.draw()
    sleep(0.1)

Edit: I also note that in the qt backend, there figure and plot are shown immediately, in contrast to the ipympl behaviour.

[ianhi]

A workaround that works with the current version is:

%matplotlib widget
from matplotlib import pyplot as plt
from time import sleep
import numpy as np

def display_immediately(fig):
    canvas = fig.canvas
    display(canvas)
    canvas._handle_message(canvas, {'type': 'send_image_mode'}, [])
    canvas._handle_message(canvas, {'type':'refresh'}, [])
    canvas._handle_message(canvas,{'type': 'initialized'},[])
    canvas._handle_message(canvas,{'type': 'draw'},[])
    
    
with plt.ioff():
    fig = plt.figure()

display_immediately(fig)

for i in range(10):
    x, y = np.random.random(2)
    plt.scatter(x, y)
    fig.canvas.draw()
    sleep(0.1)

[ianhi]

And it seems to work fine. The first animation won’t have the correct DPI, but the next ones will have the right one (because we now save the DPI as a static Canvas property)

I think guessing a DPI of 1 is a reasonable strategy? and then once the communication of the true DPI happens we can immediately redraw in the case that the DPI is different. Although faking the messages like this may not be strictly optimal instead of just calling the underlying methods.