GeezerVison

This looks good. Thanks @eyurtsev. It'd be good to pull the functionality out of the main figure function and into its own function. Also, when resizing animations, the animation frames are still updating the grayed out box - truthfully though, I'm not sure I'm 100% supportive of the graying out of the figure - that isn't the behaviour I get with other backends, and sometimes you want to resize the figure based on what the figure looks like (for instance, you might want to resize to optimize axes space for equal-aspect plots).

Also, did you test this with the nbagg backend?

Graying out the figure:

I agree I'd be happier if this could look exactly like the other
backends.

On my machine the plot wasn't updating quickly enough to render in real
time, so I found it more useful to work with a place holder for the figure
when resizing.

animations:
I have never used animations in matplotlib, so wouldn't even have known to check this.

nbagg:

The pull request is missing a var in front of the variable ctx.
ctx = fig.context; -> var ctx = fig.context;

Without this correction it fails in nbagg! (I wonder why it works with webagg)

I can submit a new pull request either implementing the issue with the variable or else entirely removing the graying out behavior. (But it'll be only in a few weeks.) I can also factor out the functionality out of the figure, but that can take sometime since I'll need to study the code more carefully. Let me know what you'd prefer.

@eyurtsev Any interest in reviving this PR?

On my machine the plot wasn't updating quickly enough to render in real time, so I found it more useful to work with a place holder for the figure when resizing.

How about we limit the number of redraws when resizing - something like 1.5Hz would be a reasonable rate when resizing.

@tacaswell sorry just saw your message. i need to fix my github email preferences...

@pelson

I actually removed the debouncing in the new PR. It seems to be unnecessary now that the mouse events are ignored while resizing.

Closing in favor of #4035.

@eyurtsev Please correct me if I am confused. In the future you can also use push/forcepush to update a PR with additional/brand new commits.

The PR tracks a merge from a fixed branch name, not from a fixed commit.

@tacaswell thanks for the information! I have only made a few PRs to date, and never revised one, so I wasn't sure how to do it.

Anyway, I applied the changes on top of the running master, so less changes to merge now. :)