Bug Hunting Session
Bug 99508 - HiDPI scaling broken on Wayland with GTK3
Summary: HiDPI scaling broken on Wayland with GTK3
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.3.0.1 target:5.2.4
Keywords:
: 100613 103220 (view as bug list)
Depends on:
Blocks: HiDPI Wayland GTK3
  Show dependency treegraph
 
Reported: 2016-04-26 10:54 UTC by Michael Rapp
Modified: 2016-12-24 15:11 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of Libre Office Writer being up-scaled too much on Wayland with GTK3 (324.68 KB, image/png)
2016-04-26 10:54 UTC, Michael Rapp
Details
Screenshot with font scaling workaround (416.95 KB, image/png)
2016-07-24 18:42 UTC, Sanya Rajan
Details
Correctly scaled, but blurry UI when using GDK_DPI_SCALE=0.5 parameter (253.56 KB, image/png)
2016-07-24 22:02 UTC, Michael Rapp
Details
screenshot at 3200x1800 showing blurriness and titlebar text shrinkage with GDK_DPI_SCALE=0.5 (662.70 KB, image/png)
2016-07-27 23:46 UTC, Nathan Smith
Details
Screenshot of LibreOffice Writer on Dell XPS 13 2015 in Wayland mode (3.75 MB, image/png)
2016-10-12 14:27 UTC, Eyal Kalderon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rapp 2016-04-26 10:54:29 UTC
Created attachment 124645 [details]
Screenshot of Libre Office Writer being up-scaled too much on Wayland with GTK3

I am running Libre Office (version 5.1.2.2.0+) on a Laptop with a HiDPI screen. When using Wayland as the default display server, the UI of all Libre Office applications is up-scaled too much (see attached screenshot). When I am running a traditional X session instead, the issue disappears. These are the specifications of my system:

OS: Arch Linux 64 bit
DE: GNOME 3.20.1 on Wayland
GTK version: 3.20.3
Display resolution: 2880 x 1620 px

Maybe the reason for this issue is, that Wayland automatically scales GTK3 applications based on the display's DPI. So the HiDPI scaling is done twice - by Libre Office as well as by Wayland/GTK - causing the UI elements to have double the size they should have.
Comment 2 Buovjaga 2016-07-22 08:44:39 UTC
*** Bug 100613 has been marked as a duplicate of this bug. ***
Comment 3 Sanya Rajan 2016-07-24 18:41:24 UTC
A workaround I found is to edit the file at: .config/libreoffice/4/user/registrymodifications.xcu

Search for the following entry:
<item oor:path="/org.openoffice.Office.Common/View"><prop oor:name="FontScaling"     oor:op="fuse"><value>50</value></prop></item>

The font scaling can then be set below 80. See the attached screenshot for the results I get. The only problem is that the icons are too big, I haven't found any setting to change the scaling for those.
Comment 4 Sanya Rajan 2016-07-24 18:42:35 UTC
Created attachment 126387 [details]
Screenshot with font scaling workaround
Comment 5 Sanya Rajan 2016-07-24 21:23:30 UTC
I found that the following command works:
env GDK_DPI_SCALE=0.5 libreoffice --writer

With this the icons and font are scaled correctly and I can keep the font scaling in the options at 100%.
Comment 6 Michael Rapp 2016-07-24 21:59:58 UTC
I can confirm, that when using the command "env GDK_DPI_SCALE=0.5 libreoffice --writer", the UI is properly scaled. However, all text and icons are blurry when using this method (see attached screenshot).
Comment 7 Michael Rapp 2016-07-24 22:02:47 UTC
Created attachment 126388 [details]
Correctly scaled, but blurry UI when using GDK_DPI_SCALE=0.5 parameter
Comment 8 Nathan Smith 2016-07-27 23:46:25 UTC
Created attachment 126442 [details]
screenshot at 3200x1800 showing blurriness and titlebar text shrinkage with GDK_DPI_SCALE=0.5

I can confirm the UI blurriness with the GDK_DPI_SCALE=0.5 env var. I might also point out that this workaround also shrinks titlebar text, as you can see in the attachment. This is complete conjecture, but I don't see this env var change as playing any role in a solution for this bug.

The best practical workaround I've found, if anyone hasn't already seen this, is to set the env var SAL_USE_VCLPLUGIN=gtk

Obviously, though, that won't be a final solution for this bug, as it just switches away from GTK3 features entirely.
Comment 9 eveningsky 2016-07-28 07:09:07 UTC
This bug is not limited to Writer. It affects all LibreOffice apps on xWayland.

This bug makes LibreOffice nearly unusable on xWayland without a workaround because all the dialog boxes stretch way outside screen boundaries.

Here is a better workaround until someone can fix this, don't use gtk3:

$ env SAL_USE_VCLPLUGIN=gtk libreoffice --writer
Comment 10 Ferdinand 2016-10-11 14:36:36 UTC Comment hidden (no-value)
Comment 11 Eyal Kalderon 2016-10-12 14:27:26 UTC
Created attachment 127971 [details]
Screenshot of LibreOffice Writer on Dell XPS 13 2015 in Wayland mode

This is a big deal-breaker when using LibreOffice in Wayland mode. The UI as a whole is utterly unusable in this mode, and the GDK_DPI_SCALE=0.5 trick seen a few posts ago no longer appears to improve the situation at all. For reference, I am running LibreOffice 5.2.2 on 64-bit Arch Linux on a Dell XPS 13 2015 laptop.

Below is the standard output I see in the terminal when running Writer. It appears that something about negative widget dimensions might be the root of the problem?

(soffice:14180): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

(soffice:14180): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

(soffice:14180): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

<HUNDREDS MORE OMITTED HERE>

(soffice:14180): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug


(soffice:14180): Gtk-WARNING **: GtkAccelLabel 0x2dbe3c0 attempted to adjust its size allocation from 31,1958056732 114x1958056720 to 31,-1357882214 114x19. adjust_size_allocation must keep allocation inside original bounds
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug


(soffice:14242): Gtk-WARNING **: GtkAccelLabel 0x2427f50 attempted to adjust its size allocation from 29,2029298981 1x169108238 to 29,2113853090 1x19. adjust_size_allocation must keep allocation inside original bounds

(soffice:14242): Gtk-WARNING **: Negative content width -1 (allocation 9, extents 5x5) while allocating gadget (node menuitem, owner GtkModelMenuItem)

(soffice:14242): Gtk-WARNING **: Negative content width -1 (allocation 9, extents 5x5) while allocating gadget (node menuitem, owner GtkModelMenuItem)

(soffice:14242): Gtk-WARNING **: Negative content width -1 (allocation 9, extents 5x5) while allocating gadget (node menuitem, owner GtkModelMenuItem)

(soffice:14242): Gtk-WARNING **: Negative content width -1 (allocation 9, extents 5x5) while allocating gadget (node menuitem, owner GtkModelMenuItem)

(soffice:14242): Gtk-WARNING **: Negative content width -1 (allocation 9, extents 5x5) while allocating gadget (node menuitem, owner GtkModelMenuItem)

<HUNDREDS MORE OMITTED HERE>

(soffice:14242): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

(soffice:14242): Gtk-WARNING **: GtkAccelLabel 0x249a1e0 attempted to adjust its size allocation from 29,2029298981 1x169108238 to 29,2113853090 1x19. adjust_size_allocation must keep allocation inside original bounds
Comment 12 François Guerraz 2016-10-14 05:48:22 UTC
The latest patch set of https://bugzilla.gnome.org/show_bug.cgi?id=771841 fixes the weird menu placement issue seen in attachment #127917 [details]
Comment 13 François Guerraz 2016-10-14 05:49:49 UTC
I meant  attachment #127971 [details] sorry
Comment 14 Lucas Steinmann 2016-10-14 11:13:39 UTC

> The latest patch set of https://bugzilla.gnome.org/show_bug.cgi?id=771841
> fixes the weird menu placement issue seen in attachment #127917 [details]

I have the same issues on an HiDPI screen.

Eyal Kalderon did not mention that the issues have been introduced after updating to GTK 3.22. But this is clearly the root of the problem.

I already applied the patches you mentioned and it solves the menu placement.
Using GDK_DPI_SCALE=0.5 fixes the size of the icons but also shrink the size of the font.
My observation about the scaled images are, that they are now somehow scaled twice. Once by some instance which was added by the updated and once by another instance (GNOME??) which already scaled it before the updated.
In Eclipse where the icons are also scaled twice the second instance is SWT. Turning of the swt autoscale fixes the overlarge icons but leaves some tiny icons which, for some reason are not scaled by the other instance.

3 quarters of the screen are still clipped and no option seemed to help.
Comment 15 Khaled Hosny 2016-10-17 13:53:56 UTC
*** Bug 103220 has been marked as a duplicate of this bug. ***
Comment 16 Michael Meeks 2016-11-10 09:30:06 UTC
Tomaz - can you poke at this if it's going to be quick ? sub 1/2 day or so ?
Comment 17 Commit Notification 2016-11-23 22:42:59 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d9a6e0023c9a192850b9db00f8120fbcc4256ec9

Resolves: tdf#99508 ensure sufficient size for hidpi backing surface

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2016-11-24 11:58:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1df0bc489ae9bdfdac48bf6cb945edc3b54ab5b2&h=libreoffice-5-3

Resolves: tdf#99508 ensure sufficient size for hidpi backing surface

It will be available in 5.3.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2016-11-24 12:01:55 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c24cc40e37ffb09d6a4fa88ca9d9b9d346982cc&h=libreoffice-5-2

Resolves: tdf#99508 ensure sufficient size for hidpi backing surface

It will be available in 5.2.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 yolo 2016-11-27 05:17:24 UTC
It’s been 48 hours. Should there not be a patch available at:

http://dev-builds.libreoffice.org/daily/libreoffice-5-2/Linux-rpm_deb-x86_64@70-TDF

for those looking for a deb amd64?
Comment 21 Buovjaga 2016-11-27 11:09:35 UTC
(In reply to yolo from comment #20)
> It’s been 48 hours. Should there not be a patch available at:
> 
> http://dev-builds.libreoffice.org/daily/libreoffice-5-2/Linux-rpm_deb-
> x86_64@70-TDF
> 
> for those looking for a deb amd64?

The buildbox is stuck for some reason.
Comment 22 Michael Rapp 2016-12-24 15:01:29 UTC
I just updated to Libre Office 5.2.4 on my Arch Linux system and the UI scaling does now properly work with GTK 3 enabled. Thanks for fixing this!
Comment 23 François Guerraz 2016-12-24 15:11:33 UTC
I confirm this is fixed indeed (if you ignore the ugly non-HiDPI icons). GTK3 is still not usable though because of #103174 affecting both X11 and Wayland, so sticking to gtk for now...