Created attachment 167181 [details]
7.0.3.1 on macOS Big Sur w/ Blurry Text

This is using the Internal Retina HiDPI display at 1680 x 1050 (largest scale) resolution.

Created attachment 167182 [details]
7.1.0.0-alpha1 on macOS Big Sur External Display

On an external display, the text is a lot less blurry when running macOS Big Sur.

Assuming the bug being present: I still wonder if switching to skia would do magic solving

- this
- They frame rate bug for HiDPI. Improved but still meh. bug 137468
- bug 138068

And might even reduce some of they macOS maintainment burden. 
See also 137468 comment 18 

However no clue how expensive this whole exercise would be in time and money

Probably a HiDPI and resolution issue. When I set the internal display's resolution to 1920 x 1200, the font is clear. However, once I get it to 1680 x 1050 (Most Space), the text becomes blurry. This happens regardless of Retina (HiDPI) being enabled or disabled.

*** Bug 138198 has been marked as a duplicate of this bug. ***

*** Bug 138202 has been marked as a duplicate of this bug. ***

Created attachment 167293 [details]
7.0.3.1 Calc macOS Big Sur Blurry Text

I see the blurry text in 7.0.3.1 after updating to Big Sur as well.

MacBook Pro, 15.4", 2880x1800 resolution. Doesn't go away with changing the resolution.

Text that has been entered into a cell is shown blurry ("Test 1" in the attachment)
While editing a cell, the text is shown crisp ("Test 2" in the attachment)
The status line at the bottom is also blurry.

Same symptom when shifting the LibreOffice window to the sidecar display on the iPad.

*** Bug 138211 has been marked as a duplicate of this bug. ***

*** Bug 138216 has been marked as a duplicate of this bug. ***

The text is blurred as described on Big Sur updated 15" MacBook Pro Retina, mid-2015, 2.2 quad-core i7, standard Iris Pro graphics, but is clear and normal on updated 21.5" iMac, late-2015, 2.8 quad-core i5, Iris Pro 6200 graphics. Both Macs with release version of Big Sur, and 7.0.3.1 LibreOffice.

First of all I am able to confirm that this issue affects Big Sur only:

macOS 10.14 Mojave:   no issue
macOS 10.15 Catalina: no issue
macOS 10.16 Big Sur:  Issue exists

Furthermore, issue seems to be present with retina displays (or 4k/5k displays) only. On standard displays I am unable to observe this issue.

There are several situations text is rendered sharp: when editing a Calc cell as mentioned above or text within widgets (buttons, combo boxes, etc.). Investigation of these situations may give a code pointer.

Also experiencing this under the official macOS Big Sur 11.0.1 release (20B29).

Hi,
I confirm the problem with the fonts:

macOS 10.15 Catalina + LibreOffice 7.0.0.3: no issue
macOS 10.16 Big Sur + LibreOffice 7.0.0.3 or 7.0.3:  issue exists with all  Text Document, spreadsheet, Presentation, Database....

Thanks for any help,
G.

I remember we did have this problem before with Catalina.
AFAIK - but I may be wrong - the problem got solved by updating the macos dev tool chain to the latest versions, including XCode and the sdk. 
Maybe someone can try that?

Please be so kind and don't add future "me too" comments. This bug (which is exact the same as bug 122218) is confirmed. It affects all macOS 11 Big Sur users with Retina screens. 

I try to recap what we know about this problem:

- It is only visible on Retina screens. It's not important if this screen is built-in or external. The fonts get blurry.
- The print preview in Calc is fine, i.e. it is *not* blurry - for what ever reason.
- macOS 10.14 added some breaking changes, which caused this bug. What this changes were exactly - no idea.
- macOS 10.14 also added some "legacy compatibility mode". If an application was build or at least pretends to be build with the SDK for macOS 10.13 or earlier, it would "revert" this breaking changes for that application. The workaround in bug 122218 made LibreOffice look like an old macOS 10.13 application. So it fixed this bug "for now".
- macOS 11 dropped this "legacy compatibility mode". So you have to adapt to the new way of doing things, or you get blurry text.

The problem is that we do not know what should be changed in LibreOffice, or what exactly the legacy stuff is LibreOffice is using, which was changed in macOS 10.14. Maybe it has something to do with the "Layer-Backed Views" described in the macOS 10.14 Release Notes 

https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes/appkit_release_notes_for_macos_10_14
 
Or maybe it's something completely different.

*** Bug 138236 has been marked as a duplicate of this bug. ***

Additional information:

With Xcode 12.2 and latest toolchain there are further issues during build:

Xcode 12.2 / Clang 12 / SDK 10.13: build ok
Xcode 12.2 / Clang 12 / SDK 10.14: build ok
Xcode 12.2 / Clang 12 / SDK 10.15: build ok
Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok

With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails. After replacement with a workaround further errors follow. It is currently not possible to build with SDK 11.

(In reply to Thorsten Wagner from comment #17)
> Additional information:
> 
> With Xcode 12.2 and latest toolchain there are further issues during build:
> 
> Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> 
> With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> After replacement with a workaround further errors follow. It is currently
> not possible to build with SDK 11.

Lovely. If you compile against other SDKs, do you experience the blurriness in macOS 11?

> It is currently not possible to build with SDK 11

Umm, I build LibreOffice with Xcode 12.2 using its included SDK for macOS 11 just fine? (I have never used separate SDKs.) What is it that fails for you? I use the following autogen.input:

--enable-symbols
--enable-release-build
--disable-odk
--disable-online-update
--enable-assert-always-abort
--enable-werror
--with-referenced-git=/Users/tml/lo/core
--without-export-validation
--without-java

(In reply to Alexander Barris from comment #18)
> (In reply to Thorsten Wagner from comment #17)
> > Additional information:
> > 
> > With Xcode 12.2 and latest toolchain there are further issues during build:
> > 
> > Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> > Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> > Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> > Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> > 
> > With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> > After replacement with a workaround further errors follow. It is currently
> > not possible to build with SDK 11.
> 
> Lovely. If you compile against other SDKs, do you experience the blurriness
> in macOS 11?

Yes, as Emmeran wrote above: Issue is reproducible with all SDKs on Big Sur. Currently LO is patched to appear as 10.13 application. I am trying to build LO without patch as 11 application.

(In reply to Tor Lillqvist from comment #20)
> > It is currently not possible to build with SDK 11
> 
> Umm, I build LibreOffice with Xcode 12.2 using its included SDK for macOS 11
> just fine? (I have never used separate SDKs.) What is it that fails for you?
> I use the following autogen.input:
> 
> --enable-symbols
> --enable-release-build
> --disable-odk
> --disable-online-update
> --enable-assert-always-abort
> --enable-werror
> --with-referenced-git=/Users/tml/lo/core
> --without-export-validation
> --without-java

Thank you; will doublecheck my toolchain

(In reply to Thorsten Wagner from comment #21)
> (In reply to Alexander Barris from comment #18)
> > (In reply to Thorsten Wagner from comment #17)
> > > Additional information:
> > > 
> > > With Xcode 12.2 and latest toolchain there are further issues during build:
> > > 
> > > Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> > > Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> > > Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> > > Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> > > 
> > > With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> > > After replacement with a workaround further errors follow. It is currently
> > > not possible to build with SDK 11.
> > 
> > Lovely. If you compile against other SDKs, do you experience the blurriness
> > in macOS 11?
> 
> Yes, as Emmeran wrote above: Issue is reproducible with all SDKs on Big Sur.
> Currently LO is patched to appear as 10.13 application. I am trying to build
> LO without patch as 11 application.

I also want to take a look at this. Where can you find the build instructions? I tried looking at the DocumentFoundation wiki, but the instructions look quite old.

(In reply to Alexander Barris from comment #23)
> I also want to take a look at this. Where can you find the build
> instructions? I tried looking at the DocumentFoundation wiki, but the
> instructions look quite old.
See here:
https://wiki.documentfoundation.org/Development/lode

If you use MacPorts, you must ensure that it is not in the $PATH. If you sign your git commits using gpg, you should disable that, because gettext at least for me fails to build in that case. I've made myself a "env.sh", which sets that stuff up for me. I "source env.sh" before I try to build LibreOffice.

It looks like this for me:

export GIT_CONFIG_NOSYSTEM=1
export LODE_HOME=/your/path/to/lode
export PATH=$LODE_HOME/opt/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/MacGPG2/bin:/Library/Apple/usr/bin

Note: You need at least 95 GB to build LibreOffice with debug symbols. So you may, like I do, build it on a external drive.

After lode did checkout the source, before calling autogen.sh, you should edit dev/core/autogen.input and put something like this in it:

--enable-debug
--enable-symbols
--disable-odk
--disable-online-update
--enable-assert-always-abort
--without-export-validation
--without-java
--without-doxygen
--enable-python=no

@Emmeran (and others), please, feel free to update the Wiki, to make it more relevant for newcomers.

But yeah, in my humble opinion, things would be a lot simpler if there would just be consensus to stop requiring Java by default, and stop building the ODK by default. Then at least the --without-java and --disable-odk switches wouldn't be needed to get started in a simple fashion.

I could compile it with "--without-java --without-doxygen" with Xcode 12.2 on Big Sur and without modifying the code. There are no changes, the text is still blurred. I will later try to have a look at the patch: https://git.libreoffice.org/core/+/ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21


And by the way: It's unfortunately not very beginner friendly, I was surprised, that I could manage to build it. But everything else seems to be a black hole for me, I have no clue where to start ;)

(In reply to lupurus from comment #26)
> I could compile it with "--without-java --without-doxygen" with Xcode 12.2
> on Big Sur and without modifying the code. There are no changes, the text is
> still blurred. I will later try to have a look at the patch:
> https://git.libreoffice.org/core/+/
> ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21

This patch won't help, because this patch only makes LibreOffice look like an old application built against a version 0 of the SDK. As said, Big Sur removed their compatibility with this. This patch only helps with macOS 10.15 or earlier.

(In reply to Thorsten Wagner from comment #17)
> Additional information:
> 
> With Xcode 12.2 and latest toolchain there are further issues during build:
> 
> Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> […]

Note that release builds are done on macOS 10.14 with XCode 11  with deployment target/minimum-version-required of 10.10 and against the 10.15 SDK with API features limited to 10.15 (MAC_OS_X_VERSION_MAX_ALLOWED)

Confirming Emmerans evaluation: Blurry text with SDK 11 too. Issue is the same as on macOS 10.14 and 10.15 without patch (or without compiling against SDK 10.13). Mix of sharp and blurry text depending on the situation is present on macOS 10.14 and 10.15 without patch too.

To sum up: Starting with Big Sur there is no longer a workaround and issue has to be resolved now - no need to modify build baselines.

An offtopic.

(In reply to Emmeran Seehuber from comment #24)
> Note: You need at least 95 GB to build LibreOffice with debug symbols. So
> you may, like I do, build it on a external drive.
> ...
> --enable-debug
> --enable-symbols

Don't those configures put symbols into binaries *and also* in the separate symbol files, maybe doubling space requirement? (I may be wrong...)

(In reply to Thorsten Wagner from comment #29)
> Confirming Emmerans evaluation: Blurry text with SDK 11 too. Issue is the
> same as on macOS 10.14 and 10.15 without patch (or without compiling against
> SDK 10.13). Mix of sharp and blurry text depending on the situation is
> present on macOS 10.14 and 10.15 without patch too.
> 
> To sum up: Starting with Big Sur there is no longer a workaround and issue
> has to be resolved now - no need to modify build baselines.

Ok thanks, then I don't need to take it look inside this ;)

Is there any documentation about the different source folders? Where could one start? (I don't mean it just specifically for this kind of bug, I'm thinking about trying to improve some stuff for the macOS port)

(In reply to lupurus from comment #31)
> Is there any documentation about the different source folders?

Please check READMEs in the top-level folders, like sal, vcl, sw. Also there's a "Code Overview" link available on the root Development wiki page [1].

[1] https://wiki.documentfoundation.org/Development

Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15

The text is still blurred, but I'm wondering, because setting the SDK to > 10.14 should change more things, for example that the window will adapt to the dark mode.

(In reply to lupurus from comment #33)
> Is there any documentation about the different source folders? Where could
> one start? (I don't mean it just specifically for this kind of bug, I'm
> thinking about trying to improve some stuff for the macOS port)

Searching for mm extension or looking into osx/aqua directories quite good pointer of macOS specific code

https://opengrok.libreoffice.org/xref/core/vcl/osx/

And for documentation: https://wiki.openoffice.org/wiki/Category:MacOSX
It's old and not up-to-date, but should still contain some relevant info

(In reply to lupurus from comment #33)
> Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk
> --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15
> 
> The text is still blurred, but I'm wondering, because setting the SDK to >
> 10.14 should change more things, for example that the window will adapt to
> the dark mode.

LO is patched at the end of the build process to behave as 10.13 application independent of the SDK in use. Beside avoiding blurred text on macOS < 11 dark mode is disabled. For now this is eligible as dark mode implementation is very incomplete - better to stay on light mode as enabling an incomplete dark mode, e.g. on systems which switch between dark and light mode automatically.

As a complete or at least a sufficient dark mode implementation is another change, fixing this bug should result in a still disabled dark mode.

(In reply to Thorsten Wagner from comment #35)
> (In reply to lupurus from comment #33)
> > Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk
> > --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15
> > 
> > The text is still blurred, but I'm wondering, because setting the SDK to >
> > 10.14 should change more things, for example that the window will adapt to
> > the dark mode.
> 
> LO is patched at the end of the build process to behave as 10.13 application
> independent of the SDK in use. Beside avoiding blurred text on macOS < 11
> dark mode is disabled.

Where can I find that patch? You can opt out for the dark mode so long: https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app#2993818

I found this:

https://stackoverflow.com/questions/4779507/font-issue-with-layer-backed-nstextview

https://stackoverflow.com/questions/3917871/creating-a-label-using-nstextfield-is-blurry

I tried to set this in salframe.cxx, but no changes:

mpNSView.layerContentsRedrawPolicy = NSViewLayerContentsRedrawDuringViewResize;
mpNSView.wantsLayer = 0;

Unfortunately I couldn't find out until now, where LO is drawing the text on the view.

Maybe I should give up searching for this, I'm too much used to Swift right now. If someone more experienced want to help me, please contact me via mail (in english or german)

> Where can I find that patch?

The patch in question is this change that was made to the LibreOffice source coce in February: https://git.libreoffice.org/core/+/ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21

The relevant part is the change to desktop/Executable_soffice_bin.mk that causes some more flags to be used when linking the soffice executable (which is the actual executable of the LibreOffice app bundle):

> -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0

which in practice, if you use the default minimum required macOS version of 10.10, expands to:

> -Xlinker -platform_version -Xlinker macos -Xlinker 10.10 -Xlinker 0.0.0

which means that the actual extra flags passed to ld are:

>  -platform_version macos 10.10 0.0.0

See the ld(1) man page for what that means.

To see this in practice, in an already-built LibreOffice tree, do:

> rm instdir/LibreOfficeDev.app/Contents/MacOS/soffice
> make verbose=t desktop

(In reply to Tor Lillqvist from comment #38)
> > Where can I find that patch?
> 
> The patch in question is this change that was made to the LibreOffice source
> coce in February:
> https://git.libreoffice.org/core/+/
> ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21
> 
> The relevant part is the change to desktop/Executable_soffice_bin.mk that
> causes some more flags to be used when linking the soffice executable (which
> is the actual executable of the LibreOffice app bundle):
> 
> > -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0

Thank you! Actually I removed those lines, but otool still showed me the min version of 10.10 and sdk n/a. 

So I changed the header with an hex editor, so that I have 

cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.15
      sdk 11.0

The app now started in the dark mode, so I know, that it uses the new SDK. There are no changes, the text is still blurred. I will take a closer look to the text drawing methods, because I also figured out, that the text in a Combobox for example is blurred as well. But I will need a lot of time to get an overview, how all this drawing works (maybe in the end I can at least help improving the dark mode :))

(In reply to lupurus from comment #39)
> (In reply to Tor Lillqvist from comment #38)
> > > Where can I find that patch?
> > 
> > The patch in question is this change that was made to the LibreOffice source
> > coce in February:
> > https://git.libreoffice.org/core/+/
> > ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21
> > 
> > The relevant part is the change to desktop/Executable_soffice_bin.mk that
> > causes some more flags to be used when linking the soffice executable (which
> > is the actual executable of the LibreOffice app bundle):
> > 
> > > -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0
> 
> Thank you! Actually I removed those lines, but otool still showed me the min
> version of 10.10 and sdk n/a. 
> 
> So I changed the header with an hex editor, so that I have 
> 
> cmd LC_VERSION_MIN_MACOSX
>   cmdsize 16
>   version 10.15
>       sdk 11.0
> 
> The app now started in the dark mode, so I know, that it uses the new SDK.
> There are no changes, the text is still blurred. I will take a closer look
> to the text drawing methods, because I also figured out, that the text in a
> Combobox for example is blurred as well. But I will need a lot of time to
> get an overview, how all this drawing works (maybe in the end I can at least
> help improving the dark mode :))

I mean, fixing Dark Mode rocks. How does it look? Does LO need updating in order for it to look correct? You can post your work here too:
https://bugs.documentfoundation.org/show_bug.cgi?id=118017

OK. Well I'm out then.

(In reply to Telesto from comment #41)
> Solving this particular problem maybe not the best investment. Even if this
> would solve the issue here. 

Please don't keep contributors from working on what they think is worth it. Thanks!

So what areas/files need to be changed/fixed in order to tackle this bug? I don't know ANY Objective-C so unfortunately I won't be much help with the code, but can help build and test when changes are made to the source.

I will take a look at the code during the next few days to isolate some code pointers...

BTW: Please let us discuss only the issue related technical details here. As LO has a good visual appearance on macOS and becomes significantly worse on Big Sur, this issue has do be fixed independent of long term considerations.

I'm sorry for drifting away a little bit with my comments about dark mode and so on. Thats just because I am new to the code base and I'm trying to understand, how the things work, so that I maybe can find a solution for this issue (this has the first priority).

As far as I understand it right now, LO is drawing everything in a NSView, it doesn't uses the native widgets of Cocoa (what would explain, that it's not that performant as a native application). But it still uses drawing methods from the Carbon framework? If so, I don't think, that Skia will help here in any way, because using the native drawing code of Apple will be necessary either way for drawing the components.

(In reply to lupurus from comment #47)
> But it still uses drawing methods from the Carbon framework? 

As far i'm aware, yes. MacOS code isn't refactored since the OoO day's, so.

Please explain what you actually mean with "Carbon". The code uses CoreGraphics, does that count as "Carbon"?

Note that the LibreOffice codebase is even worse in its choice of names, it uses the term "Aqua" in identifiers as if Aqua was some API. Maybe it was a name loosely used at some point in time in the history of macOS, but it sure hasn't been an API name a long time. If one searches for "aqua" in Xcode's Developer Documentation, nothing is found.

If one searches for "carbon", it does show some legacy APIs that Apple classifies as being "Carbon", but the functions listed as part of "Carbon Core" don't look familiar at all. And they seem to have been obsoleted since a long time, and we do have warnings for obsolete APIs turned on, so I think I can say with reasonable confidence that no, we don't use "Carbon". If somebody has concrete counter-evidence I am prepared to change that opinion, of course.

(In reply to lupurus from comment #47)
> I'm sorry for drifting away a little bit with my comments about dark mode
> and so on. Thats just because I am new to the code base and I'm trying to
> understand, how the things work, so that I maybe can find a solution for
> this issue (this has the first priority).
> 
> As far as I understand it right now, LO is drawing everything in a NSView,
> it doesn't uses the native widgets of Cocoa (what would explain, that it's
> not that performant as a native application). But it still uses drawing
> methods from the Carbon framework? If so, I don't think, that Skia will help
> here in any way, because using the native drawing code of Apple will be
> necessary either way for drawing the components.

For most tasks Cocoa calls are used (e.g. CoreText). Exception are GUI widgets: As the Cocoa document model is not used by LO, these are drawn using Carbon (HIWidgets). Text within these widgets is rendered by separate CoreText calls from LO code. This approach was common during the Carbon days and has been choosen to be consistent with the other GUI implementations (GTK, QT, Windows). It would be a major change to replace this with many implications to the other GUI implementations and should be not in the scope of this issue.

As a first step I suggest to look at combo boxes: Text within is sharp (CoreText). Text within dropdown lists is blurry. It has to be investigated if text within dropdown boxes is rendered by CoreText too (which I would expect) or if it is rendered by another kind of font rendering (which should be not the case).

(In reply to Thorsten Wagner from comment #51)
> For most tasks Cocoa calls are used (e.g. CoreText). Exception are GUI
> widgets: As the Cocoa document model is not used by LO, these are drawn
> using Carbon (HIWidgets). Text within these widgets is rendered by separate
> CoreText calls from LO code. This approach was common during the Carbon days
> and has been choosen to be consistent with the other GUI implementations
> (GTK, QT, Windows). It would be a major change to replace this with many
> implications to the other GUI implementations and should be not in the scope
> of this issue.
> 

Yes, this is what I found out so far. It uses the drawing methods HI.... This is part of the Carbon.framework, that was before Cocoa. Interestingly, it still works and it isn't a problem for this issue (it will be, if Apple will remove those drawing methods one day).

If you look at the code, you can see, that the Combobox itself gets drawed by this HIThemeDrawButton method. There the text is clear. The problem is the popup area and this is not drawn with this methods (I could not find out yet, where the area gets drawed). You can see it as well here: https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls#ComboBox

They write, that the area is not native.

(In reply to lupurus from comment #52)
> If you look at the code, you can see, that the Combobox itself gets drawed
> by this HIThemeDrawButton method. There the text is clear. The problem is
> the popup area and this is not drawn with this methods (I could not find out
> yet, where the area gets drawed). You can see it as well here:
> https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls#ComboBox

HIThemeDrawButton draws the graphical outline of a button only. There is no text rendering within HIThemeDrawButton. Text is placed within button by another CoreText call from the surrounding LO code.

Ah, yes, that old "native widget" thing. (I.e. controls that aren't *native* at all, just try to look "native".

If I recall correctly, what HIThemeDrawButton draws is just an image of how a button should look, and that image is then used to draw the actual button images in the dialogs. Possibly it could be replaced with something that draws a NSButton instead into an image. But in both cases, this will not make the buttons actually *behave* like real native buttons should.

But yeah, the ideal would obviously be to use so-called welded controls, like LibreOffice does on gtk3. Then we would have truly native controls.

But anyway, native or not-so-native controls have little to do with what *this* bug is about, surely?

(In reply to Tor Lillqvist from comment #54)
> But yeah, the ideal would obviously be to use so-called welded controls,
> like LibreOffice does on gtk3. Then we would have truly native controls.

This would be perfect, but I guess a lot of work ;)

> But anyway, native or not-so-native controls have little to do with what
> *this* bug is about, surely?

If it would be native controls, the text would not be blurry. But for now, the big question is: Where is the text in the popup area and all the other areas get drawed?

Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx, as far as I recall. Look for the CTFontDrawGlyphs() call.

(In reply to Tor Lillqvist from comment #56)
> Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> as far as I recall. Look for the CTFontDrawGlyphs() call.

Thank you. I am kind of frustrated right now, I tried a lot of different settings like 'CGContextSetAllowsFontSmoothing' for example... nothing helped. I am still wondering: Why is the font in the main view, the status bar, the combobox area blurred, but the text in the TOC or where you can select the text styles for example or in other menus not? Are they using different methods?

(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.
> 
> Thank you. I am kind of frustrated right now, I tried a lot of different
> settings like 'CGContextSetAllowsFontSmoothing' for example... nothing
> helped. I am still wondering: Why is the font in the main view, the status
> bar, the combobox area blurred, but the text in the TOC or where you can
> select the text styles for example or in other menus not? Are they using
> different methods?

Not having Big Sur installed, yet (and kind a reluctant to do so). So not having much to go on.. based on screenshots tend say that they stuff is painted as an image at low resolution (72/96 dpi) (without prior anti-aliasing)

Bit like saving QR code into DOCX format (and file reload). They SVG rendering simply quality simply bad (looks like miniature thumbnail quality being over-sized). And File -> Export formats do have also a bad ugly compression flaw somewhere. But surely depends on code paths :-( So not all export formats are affected 

And also which branch did you use? Master or 7.0? There where more code changes also related to anti-aliasing and image rendering (see Skia meta). Not sure if they his code simply limited to Skia or having large reach.

If so, bugs might have stacked up (worst case)? I assume you build without or include they Stephan hack while nobody actually has clue what it does? As it did work previously?

Also there is a risk that Apple dropped support for XYZ in Big Sur (or didn't notice they broke some legacy stuff nobody supposed to use anymore). So maybe Catalina without Stephan Bergmans patch? Not even remembering when/how the initial bug started. Except they Xcode magic an later-on they hack?

Note: only few things crossing my mind :-). Not saying it's of any use. However prefer to exclude some possibility's. Or might open a different perspective. 

Anyhow thanks for attempting for solving the mystery :-)

(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.
> 
> Thank you. I am kind of frustrated right now, I tried a lot of different
> settings like 'CGContextSetAllowsFontSmoothing' for example... nothing
> helped. I am still wondering: Why is the font in the main view, the status
> bar, the combobox area blurred, but the text in the TOC or where you can
> select the text styles for example or in other menus not? Are they using
> different methods?

I don't think that the problem is related to the way the text is painted, as it not only affects text, but also lines. Just open a Draw document and do some diagonal lines. You'll see that they are blurry also, but it's not that visible and apparent as it is with text. 

The AquaSalGraphics have the right scaling for their CGLayer used (i.e. fScale is 2 for retina in AquaSalGraphics::CheckContext()). For me it seems that all drawing on this CGLayer is done with a 0.5 scale and the final copy to the parent CGContext is done with a 2 scale (i.e. to compensate the 0.5 scale while drawing). I found an Object-C snippet that should allow to export a CGLayer into a PNG to valid it's contents (https://stackoverflow.com/questions/525609/use-c-with-cocoa-instead-of-objective-c), but as I have no clue about Objective-C I can not integrate that. Is there any other way to inspect whats in a CGLayer?

*** Bug 138381 has been marked as a duplicate of this bug. ***

Created attachment 167439 [details]
Sharp Text (Selected) vs Blurry (Text)

The issue is now with BigSur, it was fixed before in Catalina with a patch.
I would say that is a new issue as with the same Libreoffice 6.4.7.2, before the Update the fonts where all right, and after the MacOs update to BigSur, the same version of Libreoffice 6.4.7.2 and Libreoffice 7.0.3.1 are Blurry.

*** Bug 138460 has been marked as a duplicate of this bug. ***

(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.

Only a some old info which hidden in bug 122218

They temporal - now broken hack - for Catalina (instead they temporal solution of building with Xcode 10)
https://gerrit.libreoffice.org/c/core/+/88667/2/desktop/Executable_soffice_bin.mk

See additional comments/explanation for they old hack: 
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c190
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c194

---
FWIW: does tinkering with TinkerTool related to font make any difference? Only a thought.. There is an option or old style font rendering. There is bug report about font not being 'crisp' but kind of different of being blurry. So who knows...

And is this still being true?
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c203

I'm assuming the same severity/priority as bug 122218 is warranted here.

(In reply to Alexander Barris from comment #4)
> Probably a HiDPI and resolution issue. When I set the internal display's
> resolution to 1920 x 1200, the font is clear. However, once I get it to 1680
> x 1050 (Most Space), the text becomes blurry. This happens regardless of
> Retina (HiDPI) being enabled or disabled.

No clear improvement when modifying resolution.
We do not find the previous clarity.
I remember this happened in the same way when moving from version 5.x to version 6.

Quite annoying...

Version 7.0.3.1 on macOS Catalina was OK

Version 7.0.3.1 on masOS Big Sur NOT OK
Version 7.1.0.0.0beta1 onmasOS Big Sur NOT OK

Out of curiosity -  based on they assumption OoO working correctly... is there a working version in they LibreOffice archive.. 

https://downloadarchive.documentfoundation.org/libreoffice/old/

If so, maybe in a bibisecting range?
https://wiki.documentfoundation.org/QA/Bibisect/macOS

(In reply to Telesto from comment #72)
> Out of curiosity -  based on they assumption OoO working correctly... is
> there a working version in they LibreOffice archive.. 
> 
> https://downloadarchive.documentfoundation.org/libreoffice/old/
> 
> If so, maybe in a bibisecting range?
> https://wiki.documentfoundation.org/QA/Bibisect/macOS

I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of LibreOffice should be tested?

(In reply to Alexander Barris from comment #73)
> I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of
> LibreOffice should be tested?

Not having really systematic approach, but lets say
https://downloadarchive.documentfoundation.org/libreoffice/old/5.0.0.5/mac/x86_64/

if that one is also bad
https://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.4/mac/x86_64/ (there are no older x64 builds..)

if 5.0.0.5 being good, take 6.0.0.3

(In reply to Telesto from comment #74)
> (In reply to Alexander Barris from comment #73)
> > I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of
> > LibreOffice should be tested?
> 
> Not having really systematic approach, but lets say
> https://downloadarchive.documentfoundation.org/libreoffice/old/5.0.0.5/mac/
> x86_64/
> 
> if that one is also bad
> https://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.4/mac/
> x86_64/ (there are no older x64 builds..)
> 
> if 5.0.0.5 being good, take 6.0.0.3

6.1.0.1, 5.0.0.5, and 4.2.0.4 mysteriously segfaulted for me....

(In reply to Jean from comment #68)
> On top of that, all other Mac-compatible softwares tested (so far) do not
> show such defect.
> Moving from Version 5 to Version 6, only LibreOffice had such problem.
> 
> Just loaded OpenOffice 4.1.8. and it works perfect...

I've found certain areas within Audacity do the same - drop down menus are clear, other text is blurry. 

Doesn't help here, but LO is not alone!

(In reply to Tor Lillqvist from comment #69)
> Feel free to use Apache OpenOffice then, we won't mind!

I am too faithful for that... I have one computer on Black Sur, but that is a demonstration tool for secondary work, my main unit is still on Catalina, and I will not move till the solution has been brought.

There is a slight improvement by doing this in Terminal:

1. defaults -currentHost write -g AppleFontSmoothing -int 0 
2. reboot

I followed the instructions on this link which recommends to proceed to steps 3. and 4. but when I do that, I again find the defect.

With Steps 1 and 2, it is a little better (at least, one can work in better conditions.

https://discussions.apple.com/thread/252034861

*** Bug 138565 has been marked as a duplicate of this bug. ***

Btw, for some experimentation code, see https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c219 .

(In general, for anybody seriously pondering investigating and fixing this, it probably is a good idea to read through that bug, but yeah, not all comments are very informative.)

Technical details: What apparently is going on is that in macOS 10.14 and 10.15, views (NSView objects) were backed by a Core Animation layer if the app was built against the 10.14 SDK or later.

What Stephan Bergmann's patch (645fe53be0dc36535dba0ed684e21ca4cda80d70) does is to make the soffice binary marked as built against some unknown old SDK even if it was built with a current Xcode.

But in macOS 11.0, views are always backed by Core Animation layer, the SDK version of the program executable does not matter any longer. (This is nicely summarised by the commit message (unrelated to LibreOffice) in https://codereview.qt-project.org/c/qt/qtbase/+/322228 , for instance.)

I upgraded my MacBook Pro to macOS Big Sur 11.0.1 and then LibreOffice from 6.4.7.2 to 7.0.3. The characters were blurry on 6.4.7.2 and on 7.0.3 as well. Because of other bugs on 7.0.3 I reverted to 6.4.7.

I have done some tests with OpenOffice 4.1.8, NeoOffice 2017.23 and, unfortunately with LO6472, but I believe it gave interesting results. I hope this will help to solve the bug.

I used an external 1920*1080 HD screen connected by HDMI to the MacBook Pro.

First I set the main display to the Retina display and compared characters with the same file (an ods file) on the three apps. Moving windows from the main to the secondary and back to main display. The characters were crisp on the Retina display with NeoOffice and OpenOffice. Blurry in LO.

Then I set the main display to the external display (1920*1080). 

Of course, LO characters were blurry on the Retina display. 
But a difference appeared between OO and NO when windows were moved to the Retina display. NeoOff displayed crisp characters on Retina, but OpenOff displayed the same blurry characters as LO. 

Maybe this will give some clues.

*** Bug 138613 has been marked as a duplicate of this bug. ***

After reading comment 82, I was curious and downloaded the NeoOffice source, which - according to their marketing and comment 83 - works correct w.r.t. "crisp fonts" on MacOS 11 / Big Sur.

An "grep -ri" over the whole NeoOffice codebase for either CALayer or wantsLayer returns no hits, which IMHO strongly suggests, that the whole CALayer problem fixed by Qt mentioned in comment 82 is not the same problem LO has. If you read the original QT bug reference in the commit (https://bugreports.qt.io/browse/QTBUG-87014), you'll find that Qt has application startup problems and nothing in the bug's comments indicate anything else.

So I really doubt LO needs any adoption regarding CALayer handling.

Now for a different idea about the origin of the bug: my assumption is, that all this is "just" some scaling problem originating in the way Retina screens are handled in MacOS graphics layer. And IMHO a very strong indicator for a problem is commit 7c35d5f0669f461254668c1854291e1324b37c21. I introduced that assert and never saw it failing; but then I never had any Retina HW. And problems might have originally started with macOS 10.14, when commit e659c6a1857fbb8e5a6e8ff60fe241483eea32dd as a workaround, which converted the bitmap context for headless LO into a generic fallback. AFAIK this was introduced for https://bz.apache.org/ooo/show_bug.cgi?id=91990

And maybe my commit b14371703236160bf34480ef831e9b2244e140ee back then just made things worse.

My suggestion would be to revert commit 7c35d5f0669f461254668c1854291e1324b37c21 to see, if LO still triggers that assert and try to find out, why commit e659c6a1857fbb8e5a6e8ff60fe241483eea32dd is needed at all.

BTW: there is CGContextGetUserSpaceToDeviceSpaceTransform or CGContextConvertSizeToDeviceSpace, which could indicate some wrong mapping resulting in scaled text.

P.S. I don't have any mac HW, so I can't test myself.

Using ideas from the experimentation patch mentioned in comment #39, I think I see a clear improvement when using some combination of the tweaks from that, like:

diff --git a/vcl/quartz/salgdi.cxx b/vcl/quartz/salgdi.cxx
index 704bba1fae9c..23f93aeb9272 100644
--- a/vcl/quartz/salgdi.cxx
+++ b/vcl/quartz/salgdi.cxx
@@ -450,7 +450,16 @@ void AquaSalGraphics::DrawTextLayout(const GenericSalLayout& rLayout)
 
     // The view is vertically flipped (no idea why), flip it back.
     CGContextScaleCTM(maContextHolder.get(), 1.0, -1.0);
-    CGContextSetShouldAntialias(maContextHolder.get(), !mbNonAntialiasedText);
+
+    CGContextSetShouldAntialias(maContextHolder.get(), true);
+    CGContextSetAllowsAntialiasing(maContextHolder.get(), true);
+    CGContextSetAllowsFontSmoothing(maContextHolder.get(), false);
+    CGContextSetShouldSmoothFonts(maContextHolder.get(), false);
+    CGContextSetAllowsFontSubpixelPositioning(maContextHolder.get(), true);
+    CGContextSetShouldSubpixelPositionFonts(maContextHolder.get(), true);
+    CGContextSetAllowsFontSubpixelQuantization(maContextHolder.get(), true);
+    CGContextSetShouldSubpixelQuantizeFonts(maContextHolder.get(), true);
+
     CGContextSetFillColor(maContextHolder.get(), maTextColor.AsArray());
 
     if (rStyle.mbFauxBold)

But if I zoom in a lot, I see that the text is still rendered much different than in NeoOffice, for instance.

Created attachment 167757 [details]
Zoomed in screenshot of LO with the above patch

As can be seen, the letters are quite grey, you don't see many fully black pixels at all.

Created attachment 167758 [details]
Zoomed in screenshot of NeoOffice

Very crisp and black letters.

Anyway, my guess is that it is not through some combination of CGContextSet* calls that affect text rendering that we should fix this problem, but that indeed there is something fundamentally wrong or unnecessarily complex in how the text is rendered and eventually ends up on the screen. At some stage the rendered text perhaps passes through a non-Retina resolution intermediate stage, and after that it is of course worthless to upscale it again.

(In reply to Tor Lillqvist from comment #88)
> Created attachment 167757 [details]
> Zoomed in screenshot of LO with the above patch
> 
> As can be seen, the letters are quite grey, you don't see many fully black
> pixels at all.

Are you really sure that this has nothing to do with the CALayer? For me it seems this is still blurry because it has been upscaled. Just the more gray antialised font shading makes this less obvious.

I found this regarding CALayer and blurryness:

https://stackoverflow.com/questions/25746368/ios-drawing-in-calayers-drawincontext-is-either-pixelated-or-blurry-on-retina

It's for iOS, but maybe it applies for macOS too? At least it seems to be the same problem. No idea if the proposed fix there can be applied on macOS

No, I am *sure* this has something to do with Core Animation Layers, as I said in comment #82. That is what changed in 10.14 and 11.0, after all. But most likely the code in LO "works against the system" in some way.

Go to vcl/quartz/salvd.cxx

In bool AquaSalVirtualDevice::SetSize( tools::Long nDX, tools::Long nDY ) add this:

float fScale = 1.0f;
if (pSalFrame->getNSWindow())
    fScale = [pSalFrame->getNSWindow() backingScaleFactor];

maBitmapContext.set(CGBitmapContextCreate(pRawData, nDX * fScale, nDY * fScale, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));


Now everything is crispy clear. Unfortunately LO became extremely slow with that. Maybe someone knows more?

How can that work? Surely correspondingly more space must be allocated for the pRawData in that case, too? The docs for CGBitmapContextCreate say:

data
A pointer to the destination in memory where the drawing is to be rendered. The size of this memory block should be at least (bytesPerRow*height) bytes.

and the "height" parameter we pass with such a change is nDY * fScale, and bytesPerRow is (mnBitmapDepth * nDX) / 8, i.e. nDX * 4.

Take a look at salgdiutils.cxx in bool AquaSalGraphics::CheckContext(). I copied the code from there. It's a strange problem, because some of the text was blurred and some not. So there must be a difference between for example drawing the text in the Combobox and the text in the popup of the combobox.

But in AquaSalGraphics::CheckContext(), the first parameter to CGBitmapContextCreate() is nullptr, it is the function itself that allocates the necessary amount of memory.

(In reply to Tor Lillqvist from comment #94)
> How can that work? Surely correspondingly more space must be allocated for
> the pRawData in that case, too? The docs for CGBitmapContextCreate say:
> 
> data
> A pointer to the destination in memory where the drawing is to be rendered.
> The size of this memory block should be at least (bytesPerRow*height) bytes.
> 
> and the "height" parameter we pass with such a change is nDY * fScale, and
> bytesPerRow is (mnBitmapDepth * nDX) / 8, i.e. nDX * 4.

The interesting thing is: I get an error in the console: 'CGBitmapContextCreate: invalid data bytes/row: should be at least ...'

If I then say 

const int nBytesPerRow = (mnBitmapDepth * nDX * fScale) / 8;

instead of

const int nBytesPerRow = (mnBitmapDepth * nDX) / 8;

the text gets blurred again.

If you add this to your changed code after the call to CGBitmapContextCreate():

            SAL_DEBUG("maBitmapContext.get()=" << maBitmapContext.get());

you will see that the call actually fails. So is this much of the complexity in there actually unnecessary? Mind-boggling...

The commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=959e8ae7ea33ce94dd80ee8ea172b6db64593873 btw says:

> A known issue is that VirtualDevice also needs to take scaling
> into account, which it currently doesn't, so the text is still
> blurry on a HiDPI screen, but that was already true previously
> and is something that will be done in a different change.

But apparently that was not done while the developer still remembered what was to be done.

Not sure if relevant at all, but this might influence they font quality
https://www.macrumors.com/how-to/disable-font-smoothing-in-macos-big-sur/

(In reply to Telesto from comment #100)
> Not sure if relevant at all, but this might influence they font quality
> https://www.macrumors.com/how-to/disable-font-smoothing-in-macos-big-sur/

Tried that but didn't have any effect.

What could be a next point to investigate: Why is the text in the Combobox sharp, but the text in the dropdown not? And why is the text in the style sidebar sharp as well? Does anyone know what is the name of the sidebar component? Where can I find it in the code?

I came so far: 

1) The "normal" text in a Combobox is drawn in 

vcl/source/control/imp_listbox.cxx in

void ImplListBoxWindow::DrawEntry(vcl::RenderContext& rRenderContext, sal_Int32 nPos, bool bDrawImage, bool bDrawText)

in line 1728: rRenderContext.DrawText(aTextRect, aStr, nDrawStyle);

2) If you open the font combobox in the toolbar, this entry is using a different method, it uses a custom draw method in

vcl/source/control/imp_listbox.cxx

void ImplListBoxWindow::ImplPaint(vcl::RenderContext& rRenderContext, sal_Int32 nPos)

in line 1641: 
UserDrawEvent aUDEvt(this, &rRenderContext, aRect, nPos, bSelected);
maUserDrawHdl.Call( &aUDEvt );

3) The style entry in the styles sidebar is a treeview and gets drawn in

vcl/source/treelist/treelistbox.cxx

void SvTreeListBox::DrawCustomEntry(vcl::RenderContext& rRenderContext, const tools::Rectangle& rRect, const SvTreeListEntry& rEntry)

in line 2863: aCustomRenderHdl.Call(std::tuple<vcl::RenderContext&, const tools::Rectangle&, const SvTreeListEntry&>(rRenderContext, rRect, rEntry));

(I cannot find, what function is calling DrawCustomEntry)

----------------

So the big question is: Why is 3) sharp and 2) not? They seem to do the same. Maybe just the RenderContext is different?

Again, for what it’s worth, I am currently editing a document with tracking, and I see that the comments are clear. The ▾Comments heading above is blurry.

At a zoom of 125% the document isn’t too unreadable, though I would hate to make a career of using it this way.

*** Bug 138709 has been marked as a duplicate of this bug. ***

*** Bug 138928 has been marked as a duplicate of this bug. ***

*** Bug 138941 has been marked as a duplicate of this bug. ***

After investigation and refactoring of AquaSalVirtualDevice::SetSize and AquaSalGraphics::SetVirDevGraphics I was not able to archive sufficient results with doubeling bufferspace and scale. But there is another observation I want to share:

Replacing

const int nFlags = kCGImageAlphaNoneSkipFirst

by

const int nFlags = kCGBitmapByteOrder32Host;

in AquaSalVirtualDevice::SetSize will result in problems with image alpha channel as expected. Furthermore performace is bad and application will become unresponsive from time to time.

But text and graphics are sharp now although bitmap buffer size has not been increased. Will take a look in this direction next.

@ Tor: The parameters for AquaSalGraphics::SetVirDevGraphics seem to allow calling with either a GCLayer on a CGBitmapContext or with a CGBitmapContext only (without a GCLayer on top). As AquaSalGraphics::SetVirDevGraphics is called from AquaSalVirtualDevice::SetSize only for now, both parameters are not required. But these parameters are not the reason of blurry text and graphics when set correctly.

Just to be complete: All blurring (combo box dropdowns, Writer main window, Calc main window, etc.) is caused by double buffering from the main code using the VCL virtual device, in this case initialized by AquaSalVirtualDevice::SetSize and AquaSalGraphics::SetVirDevGraphics.

Yes, I noticed the same about the first parameter to AquaSalGraphics::SetVirDevGraphics () earlier today, and added a comment about it;)

In general, it is not entirely clear to me what the benefit of wrapping a CGLayerRef in CGLayerHolder and a CGContextRef in CGContextHolder is. But I am probably missing something.

Interesting observation: Running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice --writer

will make the text you type into the Writer window show up crisp and nice.

But running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice /path/do/document.odt

does now change how it looks.

Very weird.

But note that even in the soffice --writer case, even if the text shows up crisp, there are other problems, like the selection indicators don't show up at all if you select part of the text you have entered. The VCL_DOUBLEBUFFERING_ENABLE environment variable is related to an abandoned effort to make VCL and the way LO uses it saner, or something. Here is a discussion we just had on IRC (edited for clarity):

> tml__:   What does your comment "FIXME: this must disappear as we move to
>          RenderContext only" in vcl/source/window/paint.cxx mean?
> 
> vmiklos: It means that if application code (outside vcl) would store no state
>          during rendering (on the outputdevice), then such copying would not
>          be necessary. but today i guess we learned that app code won't be
>          changed that way (too much work).
> 
> tml__:   Idly wonders what RenderContext is.
> 
> vmiklos: RenderContext is just a typedef to OutputDevice; the idea was to not
>          paint at random times, but rather only paint when vcl gives you a
>          RenderContext. That's how practically all toolkits work.
>          But Skia, gtk3, Qt (and I would guess macOS, but haven't checked)
>          all gave up on changing non-vcl code, rather they maintain this
>          backbuffer (so non-vcl code can draw at random times) and just
>          copy the backbuffer to the final place when they get a drawing
>          context from the OS/underlying toolkit (on idle).
> 
> tml__:   I didn't even know that there had been such an attempt/wish/plan to
>          "move to RenderContext only".
> 
> vmiklos: https://speakerdeck.com/kendy/rendercontext-and-double-buffering it
>          was an effort 6 years ago. I think the hope was that this way one
>          more backbuffer can be avoided for (back then) OpenGL, and the result
>          was that, no, too much work, just do this for OpenGL (and now Skia)
>          the same way as gtk3 does. Like, if this would work, then each
>          backend would not need their own backbuffer. (But it does not work.)
> 
> tml__:   And is this RenderContext effort then the same as that which
>          introduced that VCL_DOUBLEBUFFERING_ENABLE etc? Or unrelated?
> 
> vmiklos: Same
> 
> mmeeks:  AFAIR we had some death-march to try to make it work everywhere properly; that failed in the end,
>          and we did something -much- simpler that didn't burn several engineers for weeks =)

Some first results: Text is sharp now within dropdown windows and within application windows (Writer, Calc, etc.) on retina displays too.

I am currently preparing a first revision of patch for testing (not for committing). Patch will include the following:

(1) Removal of path to handle application as being linked again 10.13 SDK

(2) salvd.cxx: Refactoring/rework of AquaSalVirtualDevice::SetSize to use quad storage size for retina displays

(3) salgdicommon.cxx: Refactoring/rework of AquaSalGraphics::SetVirDevGraphics to apply double scaling to virtual devices too

(4) salgdicommon.cxx: Refactoring/rework of AquaSalGraphics::copyBits and AquaSalGraphics::copyArea to use a new unified method AquaSalGraphics:copyScaledArea to handle sources from scaled virtual devices as well

(5) salbmp.cxx: Workaround for QuartzSalBitmap to downsample bitmaps from scaled layers (this workaround has still to be replaced by an implementation of scaled bitmaps)

(6) Environment variable VCL_FORCE_WINDOW_SCALING to activate window scaling on non retina displays too (should look the same as without window scaling, but very useful for testing on a non retina display)

Bitmap workaround causes blurry bitmap representations on retina displays as on non retina displays as well. This is desired for now, because implementation of scaling-aware bitmaps has still to be done. On retina displays it looks similar as on Mojave or Catalina.

After patch has been tested especially according to unwanted side effects, following steps have to be done:

(1) QuartzSalBitmap has to be extened to handle bitmaps from scaled sources, workaround has to be removed afterwards

(2) Environment variable VCL_FORCE_WINDOW_SCALING has to be removed and replaced by a scaling of 2.0f on macOS (and by a scaling from the main display on IOS). After application, windows are able to be moved between retina and non retina displays without showing blurry text again.

I will post a link to the patch here as soon as it is ready for testing.

Patch submitted to Gerrit:

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

Further observations:

(1) As SDK 10.13 is no longer preset, dark mode will be enabled for LO if it is enabled globally. Dark mode is currently not implemented in a usable manner for macOS. As a consequence dark mode needs to be disabled as default now, maybe controlled by an environment variable for futher development.

(2) When presenting Impress presentations LO hangs after stepping through some slides. I do not know whether this is caused by this patch for now. In debug mode FPS display is not cleared for refresh too.

I can reproduce the hang in a freshly built LibreOffice even without your patch. I will file a bug (and try to fix).

Filed bug #139535 for the hang (which is caused by an assertion failure, which the code then tries to handle, but fails).

(In reply to Thorsten Wagner from comment #120)
> Patch submitted to Gerrit:
> 
> https://gerrit.libreoffice.org/c/core/+/109072
> 
> Further observations:
> 
> (1) As SDK 10.13 is no longer preset, dark mode will be enabled for LO if it
> is enabled globally. Dark mode is currently not implemented in a usable
> manner for macOS. As a consequence dark mode needs to be disabled as default
> now, maybe controlled by an environment variable for futher development.
> 
> (2) When presenting Impress presentations LO hangs after stepping through
> some slides. I do not know whether this is caused by this patch for now. In
> debug mode FPS display is not cleared for refresh too.

Thank you very much, it seems to work!!! Just resizing the window looks funny, because the items in the toolbar are getting stretched during resizing. But that's okay for the moment.

For me, the dark mode is not activated, I don't know why. But if you experience it: For now you can opt out from the dark mode with NSRequiresAquaSystemAppearance set to true in the info.plist. More informations here: https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app#2993818

Suggested fix for the assertion failure that causes the hang mentioned above in https://gerrit.libreoffice.org/c/core/+/109083  .

Note to people following this bug: That assertion failure and hang is not as such related to this bug, I just mention it here as the hang was mentioned in an earlier comment.

I know this discussion should really be focused on getting the bug fixed.
But I wanted to say that I am impressed by Thorsten's willingness to dig into it and by his work on getting it fixed the "hard way" and not through another strange workaround.
Thanks!

Thank you all for your comments and help! I would like to ask you for your opinion concerning the next steps. From my point of view there are two possibilities:

(1) Resolve all the remaining issues (main work is to extend QuartzSalBitmap to handle scaled bitmaps and not to downsample them); commit patch to master as soon as it is complete

(2) Finalize patch with the current scope of work; commit patch early and deliver a second patch for the rest as soon as it is ready

For case 2, VCL_FORCE_WINDOW_SCALING control would be kept in place. Behaviour would be as follows:

(1) Bitmaps still remain blurry on retina displays (but it seems to be acceptable on laptop displays for now; on larger displays as on 5K iMacs or Mac Pros it will be visible)

(2) Moving windows between non retina displays and retina displays will cause blurry text again as long a non retina display is the primary display - this is the same as now on Mojave and Catalina without patch (and will be resolved by removing the VCL_FORCE_WINDOW_SCALING control and setting scaling to 2.0f as default on macOS)

I am in favor of no. (1) for two reasons:
* While you're at it, it's great for the community that you strive to really solve all the problems. Splitting it up always runs the risk that step 2 never gets done because other tasks surface :-)
* There is enough time until cut-off for 7.2. Backporting to 7.1 (if feasible) afterwards is a "nice-to-have" option

(In reply to Thorsten Wagner from comment #126)
> Thank you all for your comments and help! I would like to ask you for your
> opinion concerning the next steps. From my point of view there are two
> possibilities:
> 
> (1) Resolve all the remaining issues (main work is to extend QuartzSalBitmap
> to handle scaled bitmaps and not to downsample them); commit patch to master
> as soon as it is complete
> 
> (2) Finalize patch with the current scope of work; commit patch early and
> deliver a second patch for the rest as soon as it is ready
> 
> For case 2, VCL_FORCE_WINDOW_SCALING control would be kept in place.
> Behaviour would be as follows:
> 
> (1) Bitmaps still remain blurry on retina displays (but it seems to be
> acceptable on laptop displays for now; on larger displays as on 5K iMacs or
> Mac Pros it will be visible)
> 
> (2) Moving windows between non retina displays and retina displays will
> cause blurry text again as long a non retina display is the primary display
> - this is the same as now on Mojave and Catalina without patch (and will be
> resolved by removing the VCL_FORCE_WINDOW_SCALING control and setting
> scaling to 2.0f as default on macOS)

I feel like, as a user, I would want the whole bug fixed correctly and completely, not something that is thrown together and hoped to be worked on at a future date. So I'm in favor of 1. As much as 2 can work, we're still on RC1 for 7.1, and because this is targeted for 7.2, it means that it doesn't need to be hastily thrown in.

Alexander, nobody has said that this is "targeted for 7.2 [only]". Back-porting to 7.1 is not hard and I don't see why that would not be done. (That is what is done with important bug fixes, they are almost always back-ported to the stable branch from master.)

Even back-ports to 7.0 (for LibreOffice Vanilla in the App Store) and cp-6.4 (for Collabora Office in the App Store) will certainly be considered.

(In reply to Tor Lillqvist from comment #129)
> Alexander, nobody has said that this is "targeted for 7.2 [only]".
I think Alexander was misunderstanding what "target:7.2.0" in the Whiteboard field means.

That tag was added automatically with the commit in comment 113.  I've now removed it.

I am in favour of option 2. (Finalising the current patch should include dropping the gratuitous whitespace changes from it. But I am sure Thorsten knows that.)

(In reply to Tor Lillqvist from comment #131)
> I am in favour of option 2.

Totally agree. Additionally, creating too large patches will make it more difficult to see the actual reason of possible regressions; patches should be as small as possible for a certain limited functional change.

Ok, keeping this all in mind I will proceed this way:

(1) Finalize patch with current scope of work (hopefully during next weekend): Thorsten

(2) Code review and commit to master: Tor

(3) Port to cp branches (maybe): Tor

(4) Extend QuartzSalBitmap (earliest in two weeks) and prepare a second patch: Thorsten

(5) Code review and commit to master when it is ready

(6) Cherry pick for release branch and backport when all is ready

@ Tor: Hope this is ok for you!

Remaining discussion concerning the current patch will take place on the code review pages.

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a167625314bf36b735176ed488e6ba9b5e9b675

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.2.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.

Additional information concerning performance:

I had the opportunity to test on a large rentina display (iMac Pro and Mac Pro) with macOS Catalina. Results are as follows:

LO 7.0.3: Sharp text (as expected), very bad performance, scrolling with two pages side by side in Writer unusable due to bad performance

LO 7.2.0 with patch: Sharp text (as expected), much better performance, fast scrolling with two pages side by side in Writer

Currenty CGLayer is used for layered graphics. A CGLayer is as far as I know only stored in main memory (no GPU memory). Performace impact seems to be caused by scaling within main memory (probably done by applications linked against SDK 10.13 implicitly). As memory is quad of original memory now some scaling is no longer required and performance has been increased significantly.

There are further significant optimizations possible by replacing CGLayer by CALayer (to use GPU memory) - but this is not in the scope of this change.

For the ongoing next step of extending QuartzSalBitmap I will continue to use CGLayer to keep the implementation consistent.

@ Tor: Thank you very much for merging the first patch!

Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

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

tdf#138122: Fix vcl for iOS after 1a167625314bf36b735176ed488e6ba9b5e9b675

It will be available in 7.2.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.

Installed Daily build "2021-01-18 05:05:06" on MacBookPro11,4 (15" Retina, mid 2015) with MacOS 11.1. All text is now clear. Performance seems normal. Looks like a successful patch so far.

Just installed Jan 18 Daily Build on hackintosh Big Sur 11.2 beta.  Text nice and clear in Calc and Writer.

Monitor LG 4K @ 1,920x1,080

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/44dfa5ef2ffac1740ba270978de3e1b12484b5e8

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.1.1.

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.

Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/2fc4d9acb2e04a2cb868a82a394bf23239487511

tdf#138122: Fix vcl for iOS after 1a167625314bf36b735176ed488e6ba9b5e9b675

It will be available in 7.1.1.

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.

*** Bug 133837 has been marked as a duplicate of this bug. ***

*** Bug 139806 has been marked as a duplicate of this bug. ***

For folks in CC: this bug had a fix. It would be useful that you test it with daily master from https://dev-builds.libreoffice.org/daily/master/current.html and write you result here, adding your original bug.

I've just installed daily libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-01-21_10.38.59 with Spanish language pack on macOS 11.1 (20C69) and everything looks clear again on every connected monitor (external 4K screen and macBook's internal retina display).

In Writer, the text on the main editor is crisp and other interface elements such as the font selector or the are not blurry anymore.

In Calc, the text is now clear again when leaving cell edit mode.

(In reply to Commit Notification from comment #140)
> Thorsten Wagner committed a patch related to this issue.
> It has been pushed to "libreoffice-7-1":
> 
> https://git.libreoffice.org/core/commit/
> 44dfa5ef2ffac1740ba270978de3e1b12484b5e8
> 
> tdf#138122 Add window scaling for retina displays on macOS
> 
> It will be available in 7.1.1.
> 

Thorsten, will you plan backport it to 7.0?

Daily master solves the blurriness issue in Calc for me on Big Sur 11.1.

Fonts on the 7.2.0.0Alpha0+ is looking Great
Fonts are Sharp, just the Huge Icons and and Space that everithing uses is huge, I understand the Touch approach, but soon we will need more resolution just to fit the About Libreoffice window.

(In reply to Roman Kuznetsov from comment #146)
> (In reply to Commit Notification from comment #140)
> > Thorsten Wagner committed a patch related to this issue.
> > It has been pushed to "libreoffice-7-1":
> > 
> > https://git.libreoffice.org/core/commit/
> > 44dfa5ef2ffac1740ba270978de3e1b12484b5e8
> > 
> > tdf#138122 Add window scaling for retina displays on macOS
> > 
> > It will be available in 7.1.1.
> > 
> 
> Thorsten, will you plan backport it to 7.0?

Next QuartzSalBitmap has to be modified to avoid blurry graphics too (see comment 133). Backporting is ok, but I suggest to do that when all is ready (including graphics).

(In reply to Timur from comment #144)
> For folks in CC: this bug had a fix. It would be useful that you test it
> with daily master from
> https://dev-builds.libreoffice.org/daily/master/current.html and write you
> result here, adding your original bug.

Text looks perfect on my system: Retina iMac with two non-retina additional screens. I can drag the window anywhere and it looks clear everywhere.

I did note that the status bar at the bottom doesn’t take kindly to moving from one window to another. If the document was opened on the Retina screen, dragging the window to a non-retina screen causes the status bar text to render half the size, and the remain space filled with black. If the document was opened on the non-retina screen and dragged to the Retina screen, the status bar text doubles in size.

I also notice some weirdness in zoom. A document opened on the non-retina screen starts off at 125%, which is fine. However, the actual text is monstrously large. If I zoom down to 100%, it’s still large, and there’s some white space when I click left margin.

When I open up the Customize dialog on the non-retina screen, the drop-down menus are also double size.

All of this suggests that the font size is not handling the mix of retina and non-retina screens.

Would it be OK to attach a video of this behaviour?

I don’t know whether it’s my imagination, but the text appears to be drawing faster too. In the past, when I type something, there seems to be s slight lag in rendering the text.

I have only tried Writer. I also note that the Alpha version I tried has no awareness of my settings and history, so it’s not practical to test it further on a real project. I has also just crashed.

Moving windows between screens of different scale is currently not implemented. This is work in progress within the scope of this issue - the current patch is only the first patch. A video is not required (at least for me).

Drawing text should be faster as prior to patch. Drawing graphics is work in progress too and is currently not faster as prior to patch.

Note for moving that there are See Also bug 85499 and (a duplicate?) bug 108801.

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1-0":

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

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.1.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.

Patch has been merged to LO 7.1.0 which is RC 2 now. This was not planned (see comment 133). However multiple display configurations should be supported to use patch in a release. Thus I prepared a second patch:

(1) Display scaling is activated if a single retina display is present at least (independent whether this is the main display or not). Moving windows between displays is now possible in all multi-display configurations. Issue reported in comment 152 should be fixed.

(2) As implementation of window scaling for bitmaps is still ongoing and will take some time (not trivial) window scaling is not activated generally. This is planned for the complete implementation prime. Selective activation of display scaling is required to avoid performance degradation on non-retina-only configurations. This degradation would not significant but present due to upscaling and downscaling of bitmaps.

(3) Adding displays while LO is running is not supported by this patch. Adding a retina display to non-retina-only configurations causes no change in display scaling. Quitting and restaring LO is required in this case (should be acceptable for now).

Please find the second patch here:

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

It would be very nice to get it reviewed, tested, and merged to LO 7.1.0 before LO 7.1.0 will be published. This will help to avoid tickets.

Hwllo Thorsten. Thanks for your work on this long-standing bug. 
I'm not in MacoS so please clarify: is latest patch related to bugs from See Also and Comnent 154?
If so, you may well close this one as Fixed and confines there, or close the other one referencing the commit. Thanks.

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

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

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.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.

Thorsten, you write "This was not planned", but even the first patch did fix things significantly for a significant number of of users, and did not introduce any new problems, right? So why not get it out there?

(In reply to Tor Lillqvist from comment #159)
> Thorsten, you write "This was not planned", but even the first patch did fix
> things significantly for a significant number of of users, and did not
> introduce any new problems, right? So why not get it out there?

It is ok to get it out now, but handling of multiple displays was not prepared for end users (control by environment variable). This has been dropped with the second patch to make it ready for end users.

(In reply to Timur from comment #154)
> Note for moving that there are See Also bug 85499 and (a duplicate?) bug
> 108801.

Yes, these two issues should be fixed by second patch.

*** Bug 139945 has been marked as a duplicate of this bug. ***

*** Bug 139950 has been marked as a duplicate of this bug. ***

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

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

Revert "tdf#138122 Detect window scaling for multi display configurations on macOS"

It will be available in 7.2.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.

I tested the latest dev version (build 7.1.1.0) and tested with Draw, Impress and Writer, and accross all these apps fonts are perfect. Many thanks for the fix !

(In reply to Frank Fuchs from comment #166)
> Thorsten and Stephan:
> 
> I noticed that Thorsten's patch for "Detect window scaling for multi display
> configurations on macOS" was reverted by Stephan.
> Is there a new patch in the works?

As soon as I get Stephan's broken unit tests reproduced. I am working on this but on my build chain there are many unit tests broken not only those mentioned by Stefan and not only those which are possibly related to this issue - maybe an issue with my build environment but not identified until now.

*** Bug 140430 has been marked as a duplicate of this bug. ***

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0c36f364b14aacd0eeb53087ae2fce54402dc741

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.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.

Hi, 
I tested today daily build 7.1.2.0.0+ on MAC OSX 10.16, and the text appears sharp and clean on Writer and Calc. The problem seems to be solved. 
thumbs up!

(In reply to Yves Bertran Alvarez from comment #170)
> Hi, 
> I tested today daily build 7.1.2.0.0+ on MAC OSX 10.16, and the text appears
> sharp and clean on Writer and Calc. The problem seems to be solved. 
> thumbs up!

No, issue is not resolved completely. Text is working, Performance is ok, but bitmaps are a litte bit blurry. The latter is caused by a workaround currently in place. Bitmaps are work in progress. Issue will be resolved when scalable bitmaps have been implemented too.

Fonts are clear, images are blurry

*** Bug 140761 has been marked as a duplicate of this bug. ***

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

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

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.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.

Backport of multi display support for LO 7.1 submitted to Gerrit:

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

Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/6b3558e3c563427f1bdff7193151c57c59041ddb

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.1.2.

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.

*** Bug 140864 has been marked as a duplicate of this bug. ***

*** Bug 140858 has been marked as a duplicate of this bug. ***

I got a feedback from my friend about macOS blur fonts/images on Retina display after Thorsten's patches - it looks fine and he tried with two displays , one is Retina and second isn't. He moved LO's window from one to second and back. It looks nice too.

It works. I just tested it on my retina with Big Sure, and it works perfectly. As said Roman, I transfered the window from one not retina screen to the retina, and it goes smoothly. I was a little bit sad until this evening, and know I enjoy my LO on retina.
Well done ! Nice job ! Thank you !

I tried yesterday LibreofficeDev v7.1.3 and it works fine on a retina mac. Thanks for solving the issue!

Text issues are fixed for retina displays and for mixed display configurations. All fixes will be released with LO 7.1.2.

There are issues with bitmaps but these issues do not seem to be related to the changes in the scope of this issue and will be investigated here:

https://bugs.documentfoundation.org/show_bug.cgi?id=141063

Furthermore bitmaps are not displayed using retina quality. This is not as severe as it looked like with LO 7.1.1 because something other has changed in the meantime (see tdf#141063 too).

I am closing this record now because further development of retina quality bitmap rendering will take place here (this includes the reenablement of some on macOS currently disabled unit tests in the future):

https://bugs.documentfoundation.org/show_bug.cgi?id=141065

Thank you all for the discussions and for testing.

*** Bug 141253 has been marked as a duplicate of this bug. ***

*** Bug 141308 has been marked as a duplicate of this bug. ***

*** Bug 141344 has been marked as a duplicate of this bug. ***

*** Bug 141431 has been marked as a duplicate of this bug. ***

*** Bug 140237 has been marked as a duplicate of this bug. ***

*** Bug 140423 has been marked as a duplicate of this bug. ***

*** Bug 140390 has been marked as a duplicate of this bug. ***

*** Bug 141494 has been marked as a duplicate of this bug. ***

Created attachment 178006 [details]
writer on external display

Created attachment 178007 [details]
writer on retina display

7.3.0 seems to reintroduce the issue (more #140390 or #140237 but those were marked as duplicates of this one).

Macbook Pro M1 (Silicon), macOS Monterey 12.1. External (27" WQHD).

LO upon starting opens on main display (external display configured as such) and everything is scaled 2x (or only 1/4 of the window is visible). If I open any document it keeps this scale. Moving window to another display doesn't change scaling (see screenshots).

But! If I close LO window (cmd+w) and re-open LO window (on macOS you can close all application windows but keep application running) from the dock then it opens on the MBP display and it's scaled properly. If I then move the window to the external display the scale is maintain correctly.

I don't use Mac but from QA point of view:
if bug was closed it can only be reopened if fix wasn't correct.
Here, that's not the case, so I close again, external monitor needs another bug. 

Closing this bug should've included testing all the dupes, which I don't see as done. Bug 108801 is also reopened. 
So new bug can be created or maybe #140390 or #140237 can be reopened to keep those reporters in the loop, not all have external monitor. Important is to See Also link to this bug.

Issue seems to be related to with LO 7.3 newly introdurced Skia functionality. I was able to reproduce and issue disappears with "Use Skia for all rendering" in Preferences/View unchecked.

Could someone please confirm this? If issue is releated to Skia a new ticket should be filed keeping Luboš Luňák in the loop.

@Timur
> if bug was closed it can only be reopened if fix wasn't correct.
> Here, that's not the case, so I close again, external monitor needs another bug. 

My bad. Various organisations treat reporting differently (sometimes preference is to open new ones, sometimes to avoid "noise" to add comments to existing ones). The reopening would relate more to https://bugs.documentfoundation.org/show_bug.cgi?id=140390 (Writer does not scale with an external monitor) but that one was closed as duplicate of this one so the logic would dictate that the issue form 140390 had the same origin as this one thus I decided to re-open this one.

@Thorsten Wagner
When I disabled Skia it started to work correctly again (also, with Skia enabled printing doesn't work and only a blank page is shown in print preview / printed but that's separate issue)

Wojtec: please file a new bug for blurryness issue under macOS Monterey.
Print preview bug is https://bugs.documentfoundation.org/show_bug.cgi?id=146842

*** Bug 139950 has been marked as a duplicate of this bug. ***