** Tags removed: bionic
** Tags added: focal
** Changed in: mutter (Ubuntu)
Status: Won't Fix => New
--
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:
New
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 : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
