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
{{ message }}
Repository navigation
[Bug]: Graph gets cut off with scaled resolution using gtk4cairo backend #25847
When using the gtk4cairo backend, and using a scaled resolution, part of the graph will be cut off.
From the bug reports on Graphs, it seems like with 200% scaling, only 1/2 of the screen is used, and at 300% scaling it's about 1/3 of the screen etc...
See attached screencast. It goes back to normal when scaling is set to 100%.
Screencast.from.2023-05-10.10-45-40.webm
Code for reproduction
importmatplotlibmatplotlib.use("gtk4cairo")
importmatplotlib.pyplotaspltimportnumpyasnp# Data for plottingt=np.arange(0.0, 2.0, 0.01)
s=1+np.sin(2*np.pi*t)
fig, ax=plt.subplots()
ax.plot(t, s)
ax.set(xlabel='time (s)', ylabel='voltage (mV)',
title='About as simple as it gets, folks')
ax.grid()
fig.savefig("test.png")
plt.show()
Actual outcome
The plot should always stretch over the entire area, and never cut off.
Expected outcome
The plot is cut off when using a scaled resolution. Note that it works fine with the gtk4agg backend, so it's definitely a bug in gtk4cairo. However, gtk4agg backend has other issues that prevent me from using that in Graphs.
Additional information
I have been using Fedora 38 Silverblue on my computer, attached screencast is from a Fedora 36 toolbox. Problem persists in a Flatpak, and initial bug report on Graphs was from somebody running a Fedora 36 workstation desktop it seems.
Note that the filled in versions below are from the environment that runs in my Toolbox container. But the problem persists in the Flatpak which runs Gnome 44 runtimes with Matplotlib 3.7.1 installed by Pip.
See issue on Graphs for the context where I initially got confronted with this bug.
This screencast I made in the bug report in Graphs, may be a bit more illustrative. It only cuts off with scaled resolutions, but works fine as soon as it gets back to the unscaled screen. Clearly, this is not an issue on my own set-up (my dpi is too small to require scaling), but with the increasing popularity of high-dpi screens, this is quite relevant for a lot of people of course.
@QuLogic has been working towards improved hidpi support recently. I'm not sure if this presentation has been directly in his sights as of yet, but may be at least related.
This should have been working since at least 3.5.0 #21025. If it's not working now, there's been a regression somewhere. I'm fairly certain I've tried it out more recently than that and it was fine, but don't remember exactly. Unfortunately, I can't really test this while my laptop is out of commission.
I tried it directly using Matplotlib 3.6.3 with the same results. Yesterday I actually stumbled upon that PR and I'm fairly certain I tried it with the commit corresponding to that PR to compile Matplotlib, and also there the difference was not really different. Perhaps it's some changes in how gtk handles things? I'll check how it handles in X11 compared to Wayland as well. Maybe that can explain the difference.
I tried using the "plain" Matplotlib 3.5.3, but I'm getting errors related to the css
Traceback (most recent call last):
File "/app/lib/python3.10/site-packages/graphs/main.py", line 140, in do_activate
self.canvas = Canvas(self)
File "/app/lib/python3.10/site-packages/graphs/canvas.py", line 34, in __init__
super().__init__(self.figure)
File "/app/lib/python3.10/site-packages/matplotlib/backends/backend_gtk4cairo.py", line 17, in __init__
super().__init__(figure)
File "/app/lib/python3.10/site-packages/matplotlib/backends/backend_gtk4.py", line 98, in __init__
css.load_from_data(b".matplotlib-canvas { background-color: white; }")
Thanks for the pointer, so I tested out Matplotlib 3.5.3 with the fix from #25280 (I basically just took the latest build in the 3.5.x branch and copied the CSS fix in, see https://github.com/Sjoerd1993/matplotlib/tree/testbreanch), and there indeed the bug does not exist there, you were correct about it being a regression!
I also tried the same with the Matplotlib 3.6.x branch, and there this bug is present. So the regression happened somewhere between 3.5.3 and the latest version of 3.6.x.
Activity
sstendahl commentedon May 10, 2023
This screencast I made in the bug report in Graphs, may be a bit more illustrative. It only cuts off with scaled resolutions, but works fine as soon as it gets back to the unscaled screen. Clearly, this is not an issue on my own set-up (my dpi is too small to require scaling), but with the increasing popularity of high-dpi screens, this is quite relevant for a lot of people of course.
Schermopname.van.2023-05-09.17-19-13.webm
ksunden commentedon May 10, 2023
@QuLogic has been working towards improved hidpi support recently. I'm not sure if this presentation has been directly in his sights as of yet, but may be at least related.
QuLogic commentedon May 11, 2023
This should have been working since at least 3.5.0 #21025. If it's not working now, there's been a regression somewhere. I'm fairly certain I've tried it out more recently than that and it was fine, but don't remember exactly. Unfortunately, I can't really test this while my laptop is out of commission.
sstendahl commentedon May 11, 2023
I tried it directly using Matplotlib 3.6.3 with the same results. Yesterday I actually stumbled upon that PR and I'm fairly certain I tried it with the commit corresponding to that PR to compile Matplotlib, and also there the difference was not really different. Perhaps it's some changes in how gtk handles things? I'll check how it handles in X11 compared to Wayland as well. Maybe that can explain the difference.
I tried using the "plain" Matplotlib 3.5.3, but I'm getting errors related to the css
QuLogic commentedon May 11, 2023
You would need #25280, though you can just comment that out.
sstendahl commentedon May 11, 2023
Thanks, I'll give it a try with that PR!
Also, Wayland or X11 doesn't matter. Same results.
sstendahl commentedon May 11, 2023
Thanks for the pointer, so I tested out Matplotlib 3.5.3 with the fix from #25280 (I basically just took the latest build in the 3.5.x branch and copied the CSS fix in, see https://github.com/Sjoerd1993/matplotlib/tree/testbreanch), and there indeed the bug does not exist there, you were correct about it being a regression!
I also tried the same with the Matplotlib 3.6.x branch, and there this bug is present. So the regression happened somewhere between 3.5.3 and the latest version of 3.6.x.
gtk4: Fix Cairo backend on HiDPI screens