Repository navigation
set_size_inches() with forward=True sets the wrong size of the canvas with gtk2, gtk3 #7302
Description
version: 2.0.0b1+1773.g3590ce2, installed from source
OS: OSX 10.11.6
inside an ipython shell...
clf()
gcf().set_size_inches([4,4], forward=True)
ax = subplot(111)
plot([],[])
title('title')
xlabel('x label')
grid()
subplots_adjust(bottom=0.12, top=0.9)
draw()
show()what happens to me: with gtk3, running this script the first time, the window pops up, everything is fine. If I then run this script again without doing anything else: the window doesn't change size, but the figure canvas does, pushing the title and the top part of the plot above the top of the window. If I then grab the window resizer and change the size of the window, I see the entire plot (so that signal works).
with gtk2, the same behavior occurs except: the part of the canvas that disappears is the bottom of the plot instead of the top.
As an aside, when this happens, before resizing the window, the zoom-to-rectangle function grabs a rectangle that is offset from the mouse pointer.
Hypothesis: the code is counting the toolbar extents as part of the size of the canvas.
[edited to add code markup tacaswell]
Activity
kaufman commented on Oct 18, 2016
the OSX backend appears to resize the canvas, but doesn't resize the window at all.
kaufman commented on Oct 18, 2016
The 'qt' and 'qt4' backends do not appear to have this bug.
tacaswell commented on Oct 19, 2016
@OceanWolf @fariza RE gtk
@mdehoon RE osx
OceanWolf commented on Oct 19, 2016
Yes, lots of horrible inconsistent API usage that I fix with MEP27, see http://matplotlib.org/devel/MEP/MEP27.html#backward-compatibility
janssen commented on Feb 1, 2017
The default for the 'forward' argument to figure.set_size_inches changed silently from 1.4.3 to 2.0.0, from 'False' to 'True'. Since some backends call this as part of their implementation, and don't explicitly specify a value for the 'forward' parameter, relying on the default value, this change (which is documented wrongly) caused various havocs to various back ends (including the Kivy one, which is how I found it.)
janssen commented on Feb 1, 2017
This is related to MEP 27, but a different issue.
keflavich commented on Mar 31, 2017
I'm using TkAgg as my backend on OSX, and I have what I believe is a similar issue:
tacaswell commented on Mar 31, 2017
@keflavich does that get corrected once the window is shown?
I can not reproduce this on linux. I wonder if this has something to do with retnia on mac? That can lead to weird factor of 2 resizing.
keflavich commented on Mar 31, 2017
@tacaswell No, it doesn't. And I agree, it seems very likely to be related to mac retina screens, but it seems to happen independent of whether I have an external monitor connected.
My only workaround has been to use a non-displaying backend (i.e., pdf) to make pdf figures. Using TkAgg and Qt5agg both resulted in the same problem. While I reported just the figure size issue, this manifested in pdf and png images having dramatically different font sizes for identical on-screen figures.
tacaswell commented on Apr 3, 2017
I suspect that the font size issue is due to the fonts always being sized in absolute units (points), but everything else scales with the figure size. The figures are smaller, making the fonts look relatively bigger.
QuLogic commented on Jul 25, 2020
The GTK2 backend is gone; the GTK3 backend sizing should be fixed by #16972; the macOS backend should be fixed by #16992.