Thank you for reporting this bug to Ubuntu. Ubuntu 18.04 (bionic) reached end-of-standard-support on May 31, 2023.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases We appreciate that this bug may be old and you might not be interested in discussing it anymore. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in. ** Changed in: mutter (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1755501 Title: GfxBench renders fullscreen content at wrong size in Gnome desktop (on X) Status in mutter package in Ubuntu: Won't Fix Bug description: Setup: * FullHD monitor (1920x1080 resolution) * Ubuntu 18.04 (pre-release) with Gnome/mutter 3.27.92, on top of X * GfxBench benchmark suite from Kishonti: https://gfxbench.com/ (one of the most common 3D benchmarks supporting Linux) Example test-case: * bin/testfw_app --gfx glfw --gl_api desktop_core --width 1920 --height 1080 --fullscreen 1 --test_id gl_manhattan Expected outcome: * Benchmark renders always in full monitor resolution, like happens with all other desktops (Unity, XFCE, KDE) Actual outcome: * There's a black bar at the top of the screen and benchmark content is vertically scaled to smaller size than fullscreen Same thing happens also with Ubuntu 16.04 version of Mutter (v3.18.3), so it's not a (recent) regression. I assume that any other similar test-case which: * requests full resolution fullscreen window * uses window size that it gets * but doesn't support resizing the window afterwards Would have the same issue. From xwininfo, xev and apitrace output I can see following: * Window is created in correct resolution * app sets some window properties * WM reparents it * WM maps window's parent to screen * WM resizes window's parent a smaller size -> I think this is the point when the application sets its GL viewport to wrong size * Some _NET_WM properties are set (by WM?) * WM resizes window's parent back to correct size, which is apparently too late for this application When comparing this to what Unity does: * Unity or app sets properties after reparenting * There's an extra intermediate window between the resized parent and the benchmark window * Resizing of the parent window to smaller size happens before that window is mapped on screen. I assume this means that the application doesn't get window resize event for the wrong window size * extra _NET_WM properties are set after parent is re-sized back to correct size -> this probably makes the time window with wrong window size shorter Upstream bug: https://gitlab.gnome.org/GNOME/mutter/issues/60 I'm filing this here too because: * This was tested on latest Ubuntu 18.04 * Mutter upstream bug tracker doesn't support attachments To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1755501/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
