Repository navigation
Rolling image if the FFMpegWriter dpi setting does not match that specified when a figure is created #8852
Description
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.
import matplotlib.animation
import numpy
import pylab
fig = pylab.figure(figsize=(6,6), dpi=120)
writer = matplotlib.animation.FFMpegWriter(fps=10)
x = numpy.linspace(0, 6.28, 100)
with writer.saving(fig, 'rolling_bug.mp4', dpi=100): # saving OK if dpi=120
for offset in numpy.linspace(0, 6.28, 30):
pylab.plot(numpy.cos(x-offset), color='black')
# saving OK if the next line is commented out
pylab.pause(0.01)
writer.grab_frame()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
Activity
tacaswell commentedon Jul 9, 2017
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.
tacaswell commentedon Aug 31, 2017
I can not reproduce the rolling behavior on current master.
tacaswell commentedon Aug 31, 2017
But I can still reproduce the jumping, punting to 2.1.1
anntzer commentedon Jan 28, 2018
AFAICT, closed by #10292. Feel free to request a reopen if not.