That was an explicit change came in #6339 to address some "glitches on resize on Mac/Qt".

So it seems like we may need to revert this. Can you cook up a simple example to replicate the incorrect behavior you're seeing?

Example. Python 2.7, Qt 5, PyQt5. GUI with a plot receives data points from a different thread every 3 seconds. Try to resize the window between plot updates, or after we received all the data points (10 in total). Then have a look at the DataAnimation class and uncomment _end_redraw() method. The issue will be gone.

@dopplershift, does the example work for you? Can you confirm the behaviour?

I can reproduce the problem, and I can reproduce it even more easily with some of our simpler animation examples if I tune down the refresh.

Unfortunately, your solution with matplotlib 2.1 triggers a lot of warnings (and non-functional behavior) because that ends up calling draw() from within an existing draw call. This produces warnings like

QWidget::repaint: Recursive repaint detected

and

QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::end: Painter not active, aborted

What we really need is a way to force a new draw after the other one completes...

#9505 should handle (or at least document...) most of the recursive repaint issues.

I'm also wondering if we're going about this all wrong. I wonder if there's a way to just turn off blitting entirely when a resize happens, since with blitting off everything works fine. Then let blitting return to on after the resize is taken care of.

@anntzer While I can confirm it works better on 2.1.x branch, I still definitely get messages. But I think the animation module is wrong in literally invoking recursive draws.

I have a branch where I've changed how blit + resize is changed that seems like a much better approach. I think this is going to grow into a bit of a refactor to separate out how blitting is handled (too many if blits distributed through the code).

marked as 2.2 as @dopplershift says a big refactor is coming 😈

Hi,

I finally had to update Matplotlib and my workaround started to produce QWidget::repaint: Recursive repaint detected as it was expected.

Is there any other way of solving the original issue with a blank window after resize? Big refactoring didn't seem to help. 😆

Sadly, big refactor is still half-baked on my hard disk. 😱

Do you think I can help somehow with this specific problem? Or is it too big and complex for someone not familiar with the codebase?

You're welcome to take a look at my branch here: https://github.com/dopplershift/matplotlib/tree/anim-blit2

I know I found the blitting stuff to be a little tricky, mostly because we don't control when the GUI frameworks actually complete a draw.

@wombatonfire What version are you using? I thought we had squashed all of the recursive re-paint issues....

@tacaswell The recursive re-paint issue appears if I override self._post_draw() in _end_redraw() and, as I understood, it is expected, it's not a matplotlib problem, but a problem of my workaround, which worked previously on v2.0.2.

The real problem for me is that I loose existing data on a real-time plot after resize, until new data points arrive. That's the core issue.

That sounds like we are missing a "and re-draw the animated artsts" call just after we regenerate and capture the background.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!