mpl 2.0.2 and master (but most likely since ever).
Blitting-based animations place artists imprecisely at the subpixel level, as shown by the following screenshot from examples/animations/dynamic_image.py.
Note that the bottom-most and right-most row of the image does not line up with the axes; instead some earlier image "leaks" through; likewise the top and left axes are occluded.
(This is from the qt5agg backend; interestingly gtk3agg and tkagg have slightly different (but similar) artefacts.)
Removing the "blitting" flag gets rid of this issue (the image becomes correctly aligned with the axes.
I think the reason is that the way drawing (including blitting) is implemented is that Agg/Cairo renders to a temporary buffer (necessarily integer-sized), which gets transfered to the screen in a later stage (by the GUI-specific code); the screen may already have some drawings on it (especially in the case of blitting animations) and we are unable to render the image with a non-integer origin. Instead, a better way may be to grab whatever is on screen as the starting value of the buffer, and let Agg/Cairo render in top of that.
See e.g. http://doc.qt.io/qt-4.8/qpixmap.html#grabWidget or perhaps rather http://doc.qt.io/qt-4.8/qpixmap.html#grabWindow, etc.
On a similar issue, note that copy_from_bbox currently truncates the coordinates of the bbox (_backend_agg.cpp):
agg::rect_i rect(
(int)in_rect.x1, height - (int)in_rect.y2, (int)in_rect.x2, height - (int)in_rect.y1);
It may be better instead to expand the bbox to the nearest integer coordinates. This may accidentally overlap (at subpixel level) with some neighboring, really close object, but at least this won't truncate the bbox we were trying to grab. Likewise, the semantics of restore_region for non-integer coordinates could be clarified.
mpl 2.0.2 and master (but most likely since ever).
Blitting-based animations place artists imprecisely at the subpixel level, as shown by the following screenshot from examples/animations/dynamic_image.py.
Note that the bottom-most and right-most row of the image does not line up with the axes; instead some earlier image "leaks" through; likewise the top and left axes are occluded.
(This is from the qt5agg backend; interestingly gtk3agg and tkagg have slightly different (but similar) artefacts.)
Removing the "blitting" flag gets rid of this issue (the image becomes correctly aligned with the axes.
I think the reason is that the way drawing (including blitting) is implemented is that Agg/Cairo renders to a temporary buffer (necessarily integer-sized), which gets transfered to the screen in a later stage (by the GUI-specific code); the screen may already have some drawings on it (especially in the case of blitting animations) and we are unable to render the image with a non-integer origin. Instead, a better way may be to grab whatever is on screen as the starting value of the buffer, and let Agg/Cairo render in top of that.
See e.g. http://doc.qt.io/qt-4.8/qpixmap.html#grabWidget or perhaps rather http://doc.qt.io/qt-4.8/qpixmap.html#grabWindow, etc.
On a similar issue, note that copy_from_bbox currently truncates the coordinates of the bbox (_backend_agg.cpp):
It may be better instead to expand the bbox to the nearest integer coordinates. This may accidentally overlap (at subpixel level) with some neighboring, really close object, but at least this won't truncate the bbox we were trying to grab. Likewise, the semantics of restore_region for non-integer coordinates could be clarified.