-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Rolling image if the FFMpegWriter dpi setting does not match that specified when a figure is created #8852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The problem is that when you update the on-screen graphic it re-draws it's self at 100 DPI. This means that the rendered image takes up a different number of pixels so the GUI window needs to be resized. In the vertical direction we need to make space for the toolbar so the GUI window is set to the size of your graph + the toolbar size. When the GUI window is resized there is a callback that in-turn resizes the figure (so that if you grab the corner of the window and resize it that way that gets reflected back down into the the figure size as you would expect). The bug is miss-padding the window size for the toolbar and probably a duplicate of #8736. |
I can not reproduce the rolling behavior on current master. |
But I can still reproduce the jumping, punting to 2.1.1 |
AFAICT, closed by #10292. Feel free to request a reopen if not. |
Bug report
Bug summary
Playback of mp4 files written by FFMpegWriter shows a rolling image if the dpi setting does not match that specified when a figure is created. In particular, this happens if the movie frame images are being displayed on the screen, e.g. during creation of the movie. (There is also an annoying flicker.)
Code for reproduction
Animation in the code below fails, resulting in a rolling image on playback of the saved mp4 movie. Either of two modifications indicated in the comments make the saved movie play back normally.
Note that commenting out the pylab.pause() call results in no image being displayed on the screen until the end of the script.
Actual outcome

Inspection of the figure vertical dimension in pixels shows that it has changed across the call to grab_frame(), from 600 to 590 in the above example. The horizontal dimension does not change.
A screen grab from VLC Media Player is shown here:
Expected outcome
The writer.grab_frame() should not change the vertical dimension of the figure.
The flickering did not occur in the last version of Matplotlib I had installed, but I do not know what version that was. I'm pretty sure the vertical image dimension also stayed constant across the grab_frame() call, since this was (abstracted from) working code from about a year ago.
Version info
Windows 8.1
Matplotlib 2.0.2
Python 3.6.1
Anaconda 4.4.0
Installed from conda
The text was updated successfully, but these errors were encountered: