Bug 141578 - Libreoffice unusable with fractional scaling on multimonitor (on plasma+wayland)
Summary: Libreoffice unusable with fractional scaling on multimonitor (on plasma+wayland)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.1.2.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 147216 147639 151218 (view as bug list)
Depends on:
Blocks: Wayland KDE
  Show dependency treegraph
 
Reported: 2021-04-09 07:29 UTC by giors_00
Modified: 2023-03-31 11:57 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Libreoffice window main screen (scaling factor 100%) (32.01 KB, image/png)
2021-04-09 07:36 UTC, giors_00
Details
Libreoffice writer on screen 2 (scaling factor=175%) (30.50 KB, image/png)
2021-04-09 07:37 UTC, giors_00
Details
Weston with two outputs, one scaled and LO kf5 running. (388.54 KB, image/png)
2022-04-07 20:31 UTC, Jan-Marek Glogowski
Details
Screencast of with v3 of Gerrit patch https://gerrit.libreoffice.org/c/core/+/132650 (5.55 MB, video/x-matroska)
2022-04-08 11:30 UTC, Michael Weghorn
Details
KF5 Backend Screenshot (117.59 KB, image/png)
2023-02-15 17:39 UTC, lrdarknesss
Details
QT5 Screenshot (116.43 KB, image/png)
2023-02-15 17:39 UTC, lrdarknesss
Details
QT6 Backend (179.01 KB, image/png)
2023-02-15 17:41 UTC, lrdarknesss
Details
QT6 backend in Wayland mode (118.21 KB, image/png)
2023-02-15 17:47 UTC, lrdarknesss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description giors_00 2021-04-09 07:29:23 UTC
Description:
Setting per monitor scaling factors simply makes Libreoffice unusable (plamsa + wayland)



Steps to Reproduce:
1.Set fractional scaling factor per monitor
2.open libreoffice
3.

Actual Results:
Libreoffice is simply unusable

Expected Results:
Libreoffice should scale accrdingly


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.2.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: kf5
Locale: es-ES (es_ES.UTF-8); UI: es-ES
7.1.2-2
Calc: threaded
Comment 1 giors_00 2021-04-09 07:36:07 UTC
Created attachment 171049 [details]
Libreoffice window main screen (scaling factor 100%)
Comment 2 giors_00 2021-04-09 07:37:44 UTC
Created attachment 171050 [details]
Libreoffice writer on screen 2 (scaling factor=175%)
Comment 3 Michael Weghorn 2021-04-12 08:55:30 UTC
Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only the second one having scaling set to 175%.

I see the behavior shown in attachment 171050 [details] if the Writer window first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling 175 %), then maximize it. However, when unmaximizing the window and maximizing it again, it looks OK and the whole area of the window is used.

This is on Debian testing with plasma-workspace-wayland 4:5.20.5-5, libqt5core5a:amd64 5.15.2+dfsg-5.

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: bcf0ed2f672646107b42cbe67e5c3c9d170bb33a
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded
Comment 4 giors_00 2021-04-12 09:24:02 UTC
(In reply to Michael Weghorn from comment #3)
> Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only
> the second one having scaling set to 175%.

Identical situation.

> 
> I see the behavior shown in attachment 171050 [details] if the Writer window
> first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling
> 175 %), then maximize it. However, when unmaximizing the window and
> maximizing it again, it looks OK and the whole area of the window is used.

Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize makes it better but I wouldn't say "ok". 

1. every time you change screen, you have to minimize and maximize. 

2. take a look at the menu bar. It is really inconsistent: on the screen with 100% scaling, it keeps showing the menu-bar 175% scaled.
Comment 5 Michael Weghorn 2021-04-12 09:30:09 UTC
(In reply to giors_00 from comment #4)
> > I see the behavior shown in attachment 171050 [details] if the Writer window
> > first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling
> > 175 %), then maximize it. However, when unmaximizing the window and
> > maximizing it again, it looks OK and the whole area of the window is used.
> 
> Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize
> makes it better but I wouldn't say "ok". 
> 
> 1. every time you change screen, you have to minimize and maximize. 
> 
> 2. take a look at the menu bar. It is really inconsistent: on the screen
> with 100% scaling, it keeps showing the menu-bar 175% scaled.

You're right, "OK" was maybe too strong, what I meant was that the most obvious problem in the screenshot (that a large part of the area is completely unused) disappears, so this might give a hint on where to look once somebody wants to analyze further.
Comment 6 giors_00 2021-07-05 16:19:55 UTC
I have been trying switching between gtk3 and qt5 plugin and have to say that with gtk3 things are going better. No globalmenu nor menu, though...
Comment 7 Michael Weghorn 2022-04-06 12:44:08 UTC
*** Bug 147639 has been marked as a duplicate of this bug. ***
Comment 8 Jan-Marek Glogowski 2022-04-07 20:31:25 UTC
Created attachment 179388 [details]
Weston with two outputs, one scaled and LO kf5 running.

I've found that I can run Bullsyeye Weston in a two screen setup with one scaled window via weston.ini:

  [core]
  xwayland=true

  [output]
  name=X1
  mode=800x600
  scale=2

  [output]
  name=X2
  mode=1024x768

and 

  weston -c $PWD/weston.ini --output-count=2

This works for LO gtk3, but kf5 is broken, interestingly just on the non-scaled screen, the other looks almost correct. But for whatever reason the start center image is tiny on 200%. It looks like LO has cached the larger fonts and scaling when moving the window form 2x to non-scaling. gtk3 is also "interesting", because it changes the layout of the windows near the border and even resizes it. That's still when completely on one screen.

Maximizing the main LO window on the scaled screen crashes LO with just Qt stuff in the backtrace (and also crashes gtk3), but works for the non-scaled screen. A kate window is maximizable on both screens and moving it between both screens works fine, so the kf5 LO should be able to work correct; but kf5 has additional Wayland libs; not sure they must be used explicitly or not. I've tried to find a way to flush the graphics cache somehow from the screen change handler to no avail in the end.
Comment 9 Jan-Marek Glogowski 2022-04-08 09:01:14 UTC
Just some finishing comment for the moment. LO VCL has basically no internal representation to handle a changed DPI / scaling factor properly. OutputDevice has     mnDPIX, mnDPIY and mnDPIScalePercentage, but these are just updated when a window is destroyed. A crude workaround would probably be to destroy and restore a window when it is moved to a different screen with different scaling.

Fixing VCL and widgets at large to support proper scaling is a lot of work. Since Gtk just has non-fractional scaling, it's way of simply upscaling the 100% output works quite well; maybe we should switch to this kind of scaling too, for the time being, seeing also bug 146297...
Comment 10 Michael Weghorn 2022-04-08 11:30:49 UTC
Created attachment 179412 [details]
Screencast of with v3 of Gerrit patch https://gerrit.libreoffice.org/c/core/+/132650
Comment 11 Commit Notification 2022-04-08 15:57:02 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/881cfbf77567194f5016a961d1c3db869734d68b

tdf#141578 Qt handle QtFrame screen changes

It will be available in 7.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2022-04-08 17:49:38 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/76de12a19bd90c0ed0d7a6a85502d3dccdbeba4e

tdf#141578 Qt handle QtFrame screen changes

It will be available in 7.3.3.

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

Affected users are encouraged to test the fix and report feedback.
Comment 13 Jan-Marek Glogowski 2022-04-08 17:52:23 UTC
This patch just prevents the min/max hassle, so LO updates the client area of the window correctly. Scaling factor change is still not handled, so I removed the target entries from the whiteboard.
Comment 14 Michael Weghorn 2022-09-29 14:58:13 UTC
*** Bug 151218 has been marked as a duplicate of this bug. ***
Comment 15 Frederic Parrenin 2022-12-02 13:08:41 UTC
Still repro in 7.4.2.3.
Comment 16 lrdarknesss 2023-02-15 17:39:01 UTC
Created attachment 185387 [details]
KF5 Backend Screenshot

I just tried out different VCL backends using the following Libreoffice version (from Arch/ Manjaro package):

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: 50(Build:3)
CPU threads: 6; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+wayland)
Locale: de-DE (de_DE.UTF-8); UI: en-US
7.5.0-1
Calc: CL threaded

I have a primary 4K screen (125% wayland scaling) and two secondary FHD screens with 100% scaling.
The screenshots are all from my primary 4K screen.

First with kf5 backend:
Comment 17 lrdarknesss 2023-02-15 17:39:44 UTC
Created attachment 185388 [details]
QT5 Screenshot

Same problem with the QT5 backend
Comment 18 lrdarknesss 2023-02-15 17:41:17 UTC
Created attachment 185390 [details]
QT6 Backend

With Qt6 it looks more or less as desired.
Interestingly, xeyes tells me, that this is in fact running in XWayland mode...?
Can i force it to somehow use the native Wayland?
Comment 19 lrdarknesss 2023-02-15 17:47:30 UTC
Created attachment 185391 [details]
QT6 backend in Wayland mode

Sorry for the spam, but I don' think that i can edit messages here or attach multiple screenshots to one post.

I found the reason for the apparently "good" scaling with QT6.
I hadn't installed the qt6-wayland package, so Qt was using XWayland.
It also reported the following in the console:

> SAL_USE_VCLPLUGIN=qt6 lowriter                                                                                                                    
> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""

After I installed the package, Libreoffice was started with Wayland support and the scaling was bad as with QT5 again.
Comment 20 Michael Weghorn 2023-03-31 11:57:59 UTC
*** Bug 147216 has been marked as a duplicate of this bug. ***