Bug 147342 - [macOS] UI Scale not working on non HighDPI external display when using Skia and a laptop with Retina display (HighDPI)
Summary: [macOS] UI Scale not working on non HighDPI external display when using Skia ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.3.0.3 release
Hardware: ARM macOS (All)
: high major
Assignee: Patrick Luby
URL:
Whiteboard: target:7.6.0 target:7.5.1
Keywords:
: 145991 (view as bug list)
Depends on:
Blocks: macOS-UI-polish Skia
  Show dependency treegraph
 
Reported: 2022-02-10 10:40 UTC by Bertrand Presles
Modified: 2023-02-02 13:11 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
A screenshot showing that the mouse pointer is not being mapped correctly to the LibreOffice UI (709.90 KB, image/png)
2022-02-10 19:22 UTC, Joel Bradshaw
Details
main build 2023-01-26 (303.08 KB, image/png)
2023-01-26 10:48 UTC, steve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Presles 2022-02-10 10:40:22 UTC
Description:
When having a non HighDPI external screen (ex: 1080p screen) connected to a MacBook Air/Pro with internal Retina display on, dragging and resizing the LibreOffice window on the external display, the UI doesn't scale correctly when Skia rendering is activated.

Steps to Reproduce:
1. Ensure to have version 7.3+ with Skia support
2. Ensure Skia rendering is enabled
3. Drag any LibreOffice window from internal laptop high dpi screen to normal dpi external display (ex: 1080p) and resize the window

Actual Results:
The UI is too big for the screen low DPI

Expected Results:
The adapts to the screen DPI correctly, even if you drag and resize window on a screen which have different DPI specs.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
System on which it was reproduced:

- MacBook Air M1 (2020)
- Dell 24" P2419HC external screen connected using USB-C
- macOS 12.2
- LibreOffice 7.3.0.3

Note: I checked the OpenGL case but of course that's Skia which is enabled in that case.
Comment 1 Bertrand Presles 2022-02-10 10:44:23 UTC
Screen record showing the bug: https://tube.cloud-libre.eu/w/85wxUbriM2SsdpWbmexqFF
Comment 2 Joel Bradshaw 2022-02-10 19:20:48 UTC
I am also experiencing this bug, and in my case at least (it is unclear if Bertrand is also experiencing this), LibreOffice is not only too big (and blurry) on the external monitor, it is also unusable, because the mouse pointer's mapping to the window does seem to be scaled - so the mouse pointer doesn't line up with where the application thinks the mouse is. I've attached a screenshot showing this, my mouse pointer is visually hovering over the "Templates" button, but the "Impress Presentation" button is highlighted, indicating that the LibreOffice window thinks the mouse pointer is approximately twice as far down the screen as it actually is.
Comment 3 Joel Bradshaw 2022-02-10 19:22:00 UTC
Created attachment 178198 [details]
A screenshot showing that the mouse pointer is not being mapped correctly to the LibreOffice UI

As mentioned above, notice my mouse pointer is visually hovering over the "Templates" button, but the "Impress Presentation" button is highlighted
Comment 4 Joel Bradshaw 2022-02-10 19:23:36 UTC
I believe Wojtek also experienced the same bug and reopened an older ticket, their screenshots and information are here: https://bugs.documentfoundation.org/show_bug.cgi?id=138122#c191
Comment 5 Bertrand Presles 2022-02-11 07:53:58 UTC
(In reply to Joel Bradshaw from comment #2)
> I am also experiencing this bug, and in my case at least (it is unclear if
> Bertrand is also experiencing this), LibreOffice is not only too big (and
> blurry) on the external monitor, it is also unusable, because the mouse
> pointer's mapping to the window does seem to be scaled - so the mouse
> pointer doesn't line up with where the application thinks the mouse is. I've
> attached a screenshot showing this, my mouse pointer is visually hovering
> over the "Templates" button, but the "Impress Presentation" button is
> highlighted, indicating that the LibreOffice window thinks the mouse pointer
> is approximately twice as far down the screen as it actually is.

Yes indeed I'm also experiencing the mouse issue you describe.
Comment 6 steve 2022-02-14 10:24:46 UTC
This is new as per confirmation by at least one other user.
Comment 7 Alex Thurgood 2022-02-15 17:02:15 UTC
Possibly a duplicate of either bug 141555 or bug 145991
Comment 8 Alex Thurgood 2022-02-26 08:24:43 UTC
FWIW, Skia rendering is supposed to be turned off by default in the upcoming 7.3.1 release.
Comment 9 Patrick Luby 2023-01-15 23:46:51 UTC
I see this after dragging a window from to Retina screen to my low DPI external monitor and then open the LibreOffice About dialog.

Interestingly, for me this bug only occurs when using Skia/Metal (both the Use Skia and Force Skia checkboxes are checked) so I will take a look around that code and see what I find.

I will post again when I have some idea what is causing this bug.
Comment 10 Patrick Luby 2023-01-17 13:53:05 UTC
I did some grokking of the Skia source code and I found the code that Skia uses to handle HiDPI display. From what I can see, Skia assumes all monitors have the same DPI as the main screen.

I found that when a window moves to a low DPI screen, Skia never updates its state and so, effectively, Skia treats all windows as being on the main screen.

I am not sure how best to fix this bug, but at least I now know the cause. I will post again when I have more news.
Comment 11 Wim M 2023-01-18 16:06:09 UTC
In line with comment 9, I also experience this bug on the most recent RC of LibreOffice, and only with skia/metal enabled.

If I drag a LO window to a non-retina external monitor, it looks fine. However, when resizing that window, it is rendered as if on a retina screen and its size doubles. This can happen with any LO window. It does not happen when skia is disabled or enabled but forced to use software acceleration.

Version: 7.5.0.2 (X86_64) / LibreOffice Community
Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58
CPU threads: 8; OS: Mac OS X 12.6.2; UI render: Skia/Metal; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded
Comment 12 Patrick Luby 2023-01-18 22:30:07 UTC
(In reply to Wim M from comment #11)
> If I drag a LO window to a non-retina external monitor, it looks fine.
> However, when resizing that window, it is rendered as if on a retina screen
> and its size doubles. This can happen with any LO window. It does not happen
> when skia is disabled or enabled but forced to use software acceleration.
> 

I can reproduce this as well when Skia/Metal is enabled. Using your steps, I have found where the Skia code sets its internal scaling factor and I am working on a fix. I am hoping to have a fix available in the master nightly builds within the next week.
Comment 13 steve 2023-01-25 18:38:15 UTC
*** Bug 145991 has been marked as a duplicate of this bug. ***
Comment 14 steve 2023-01-25 18:39:08 UTC
Upping priority. Ran into this problem on a retina mac with LO main build (using skia by default).

It was not possible to disable skia. Navigating is hard since you have to scale back 75 % since you cannot interact with the UI due to the misalignment / mis-scaling of UI and mouse pointer location.

Even after managing to untick skia in Settings a restart did not resolve this and skia was active again.

Thanks for looking into this, Patrick.
Comment 15 Patrick Luby 2023-01-25 19:57:25 UTC
(In reply to steve from comment #14)
> Upping priority. Ran into this problem on a retina mac with LO main build
> (using skia by default).

I found a way to fix this bug yesterday and I have just uploaded the following patch:

https://gerrit.libreoffice.org/c/core/+/146142/2

It is not in the nightly builds yet (maybe tomorrow?) but you can manually apply the patch if you have a local master build if you want to test it sooner.
Comment 16 steve 2023-01-26 10:48:31 UTC Comment hidden (obsolete)
Comment 17 Commit Notification 2023-01-26 14:20:10 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a0d825133656c6329c0e7e3b0b6bafbd51e87271

tdf#147342 Notify Skia that the window's backing properties changed

It will be available in 7.6.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 18 Patrick Luby 2023-01-26 14:47:54 UTC
(In reply to steve from comment #16)
> Tested todays main build MacOSX-x86_64@tb81-TDF 2023-01-26 03:32:36 from
> https://dev-builds.libreoffice.org/daily/master/current.html
> 
> The yellow document preview is a separat issue, but the issue from this bug
> here with the false scaling of LibreOffice UI is persisting with this build
> which should have Patch Set 3 as per
> https://gerrit.libreoffice.org/c/core/+/146142/

Unfortunately, my patch didn't make it into the nightly build. My patch got stuck at the "build on all platforms" step so I wasn't able to commit the patch until now. Hopefully, it will be in the 2023-01-27 build tomorrow. You can tell if a patch has been committed (and will be included in the next nightly build) if the status of the patch in the top left corner of the patch page is "Merged".

I am glad you mentioned issue 145988. I am still trying to find anything unique on machines that see unexpected color shifting. I did include a small attempt at fixing issue 145988 in the patch that fixes the UI scaling issues so I am very interested if the 2023-01-27 build tomorrow causes any change in the color shifting behavior on machine's like yours. My attempted fix for issue 145988 is to copy the window's colorspace to it Metal surface whenever a window moves to a different screen. Both my Retina screen and my external non-Retina monitor have sRGB colorspaces so my attempted fix doesn't do anything on my machine, but who knows? Maybe something will change on yours.

If issue 145988 still occurs in the next nightly build, would it be possible for you post some screen snapshots listed in https://bugs.documentfoundation.org/show_bug.cgi?id=145988#c64 ?
Comment 19 Patrick Luby 2023-01-27 20:09:50 UTC
I can confirm that my fix for this bug is in the 2023-01-27 nightly builds for both Intel and Silicon Macs. I tested on both types of Mac running macOS 12.6.3 Monterey.
Comment 20 steve 2023-01-27 23:23:50 UTC
Really happy to confirm this fix resolves the scaling issues.

Patrick, thanks so much for looking into this. This was a blocker in the skia transition on macOS.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7c3ea0abeff6e0cb9e2893cec8ed63025a274117
CPU threads: 8; OS: Mac OS X 13.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded
Comment 21 Wim M 2023-01-28 10:53:03 UTC
Thank you for this fix, Patrick.

Is there any chance that this fix can also be inserted in the 7.5 branch?
Comment 22 Patrick Luby 2023-01-28 14:32:31 UTC
(In reply to Wim M from comment #21)
> Thank you for this fix, Patrick.
> 
> Is there any chance that this fix can also be inserted in the 7.5 branch?

Thank you for reminding me. I have submitted the fix for LibreOffice 7.5.1 (I was too late for LibreOffice 7.5.0) in the following patch:

https://gerrit.libreoffice.org/c/core/+/146210

The patch needs another reviewer to approve it before it will appear in the 7.5.1 nightly builds.
Comment 23 Adolfo Jayme Barrientos 2023-02-02 13:11:19 UTC
Merged to the 7-5 branch as commit 57a886ddef0c8e4b8095e28c0c997074a5e96d22