You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
tacaswell
added this to the
2.2 (next next feature release) milestone
Jul 5, 2017
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!
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.
The text was updated successfully, but these errors were encountered: