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.
Screen record showing the bug: https://tube.cloud-libre.eu/w/85wxUbriM2SsdpWbmexqFF
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.
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
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
(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.
This is new as per confirmation by at least one other user.
Possibly a duplicate of either bug 141555 or bug 145991
FWIW, Skia rendering is supposed to be turned off by default in the upcoming 7.3.1 release.
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.
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.
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
(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.
*** Bug 145991 has been marked as a duplicate of this bug. ***
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.
(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.
Created attachment 184922 [details] main build 2023-01-26 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/
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.
(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 ?
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.
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
Thank you for this fix, Patrick. Is there any chance that this fix can also be inserted in the 7.5 branch?
(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.
Merged to the 7-5 branch as commit 57a886ddef0c8e4b8095e28c0c997074a5e96d22