Part of the problem with blitting is that nothing is triggering the python -> js communication is never getting triggered.

If you add a

  ax.figure.canvas.draw_idle()

line inside your call back it behaves as expected.

Right, although my applications were using blit precisely to be faster than re-drawing. Just curious do animation.FuncAnimation(.., blit=True), etc also do the same thing for nbagg? I'm more than happy to add a check for nbagg backend and call draw_idle() for now though.

Edit - oh ok didn't realize that draw_idle might not do a full re-draw.

Digging into this a bit more, I don't think draw_idle is doing what I think (and is in fact triggering a full re-draw after all)

%matplotlib notebook
import matplotlib.pyplot as plt

prev_artist = None
cur_y = 0.1

def onclick_handle(event):
  """Should draw elevating green line on each mouse click"""
  global ax, bg, prev_artist, cur_y
  ax.figure.canvas.restore_region(bg)
  if prev_artist:
    prev_artist.remove()
  cur_y += 0.1
  prev_artist = ax.plot([0, 1], [cur_y, cur_y], 'g')[0]
  ax.draw_artist(prev_artist)
  ax.figure.canvas.blit(ax.bbox)
  ax.figure.canvas._force_full = True
  ax.figure.canvas._png_is_old = True
  ax.figure.canvas.manager.refresh_all()
  print ("Drew line")

ax = plt.gca()
ax.plot([0, 1], [0, 1], 'r')
plt.draw()
bg = ax.figure.canvas.copy_from_bbox(ax.bbox)
ax.figure.canvas.mpl_connect('button_press_event', onclick_handle)

Sort of works, (but does not look like the restore is working correctly...

The blit implementation on the webagg canavas is a no-op the private magic I am poking at is what should be in blit and it now seems to work half the time...

And it looks like webagg keeps two Agg renderers around (so that it can do diffs).

%matplotlib notebook
import matplotlib.pyplot as plt

prev_artist = None
cur_y = 0.1

def onclick_handle(event):
    """Should draw elevating green line on each mouse click"""
    global ax, bg, prev_artist, cur_y
    ax.figure.canvas._png_is_old = True
    ax.figure.canvas._force_full = True
    ax.figure.canvas._renderer.restore_region(bg, None, None)
    if prev_artist:
        prev_artist.remove()
    cur_y += 0.1
    prev_artist, = ax.plot([0, 1], [cur_y, cur_y], 'g', lw=5)
    prev_artist.draw(ax.figure.canvas._renderer)
    ax.figure.canvas.manager.refresh_all()

    print ("Drew line")

ax = plt.gca()
ax.plot([0, 1], [0, 1], 'r')
plt.draw()

bg = ax.figure.canvas._last_renderer.copy_from_bbox(ax.bbox)
ax.figure.canvas.mpl_connect('button_press_event', onclick_handle)

Works correctly (well, until you run out of the y-range and it starts auto-scaling with out properly updating your bg).

@pelson The flip-flopping renderers break the assumptions of the _cachedRender attribute on all of the artists (half of the time). Think it is worth updating that every time through refresh_all?

🐑 turns out that _cachedRenderer is only a thing an Axes and Figure objects so fixing that up is a no-brainer.

@azjps Thank you for kicking the tires of nbagg and providing feed back 😄 .

I don't know if that has been coming through in my other comments.

I had been excited for the pending introduction of a notebook backend for a while, but only a couple of days ago did I find out that nbagg has already been around for a year 😆. Your comments as always have been really helpful in poking around.

By the way, not sure if its been pointed out before, but with or without closing the figure (and even if you explicitly call plt.close), if you run UAT 13 multiple times, the animation goes haywire, and the only way to stop it from stuttering seems to be to restart the kernel.

[edit: misremembered something.]

Eagerly waiting for this one! My use case is that I've built a user interface in Jupyter, using ipywidgets and interactive matplotlib. Updates are very slow without blitting! (Just want to render a little circle on top of a large image most of the time).

I tried making the modifications from blink1073's backend_webagg_core.py file on top of the matplotlib 2.0.2 code (pretty straightforward to do). Blitting works well for me in a notebook now, both in Windows 10 and Ubuntu. I've never committed to the matplotlib codebase before though, so hopefully someone who knows what they're doing can pick this up for 2.1. Happy to help in any way I can.

@mbewley can you open a PR with the changes? See https://matplotlib.org/devdocs/devel/contributing.html for some details, if that isn't clear drop into our gitter room (https://gitter.im/matplotlib/matplotlib) for help!

Alright, I'll give it a shot. I emailed blink1073 - he's not interested in developing this any more, so is happy for others to take on his blitting work.

Pull request done - I've made a minimal example notebook for tsting, but wasn't sure where the best place to put it is?

Code for minimal example added to pull request.

Hey, anything I can do to help get this into the 2.2 release? (and is that realistically going to happen on 30th Jan?).

You are doing the right thing to make sure this gets in and we are going to try to have an RC by Jan 30 (but this being mostly a volunteer effort deadlines are flexible).

Cool, thanks - see comments in #9240