Bug 128133 - muddy fonts in LibreOffice GUI with 125% scale in Windows 10
Summary: muddy fonts in LibreOffice GUI with 125% scale in Windows 10
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Jan-Marek Glogowski
URL:
Whiteboard: target:6.5.0 target:6.4.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2019-10-14 07:02 UTC by Roman Kuznetsov
Modified: 2020-06-04 21:10 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (371.14 KB, image/png)
2019-10-14 07:10 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2019-10-14 07:02:52 UTC
Description:
muddy fonts in LibreOffice GUI with 125% scale in Windows 10

it's a regression

Steps to Reproduce:
1. Make sure you use 125% scale in OS Windows
2. Open LibreOffice in Start Screen
3. Look at fonts

Actual Results:
muddy fonts in LibreOffice GUI with 125% scale in Windows 10

Expected Results:
good fonts in LibreOffice GUI with 125% scale in Windows 10


Reproducible: Always


User Profile Reset: No



Additional Info:
Версия: 6.4.0.0.alpha0+ (x64)
ID сборки: ccfbe8b478f3daa8b5ec07a7e48dd5fbf8556811
Потоков ЦП: 4; ОС:Windows 10.0 Build 18362; Отрисовка ИП: по умолчанию; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded
Comment 1 Roman Kuznetsov 2019-10-14 07:10:21 UTC
Created attachment 154985 [details]
Screenshot
Comment 2 V Stuart Foote 2019-10-14 13:59:32 UTC
Confirmed Windows 10 Home 64-bit en-US with

Version: 6.4.0.0.alpha0+ (x86)
Build ID: 2ef2c031ce9ec730b13fca8bca808f382aab5fe4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Default GDI rendering also affected.

As compared to 100% scaling (my default) moving to 125%, or 150% the font rendering has gotten very 'fuzzy'

Seems recent issue, not sure when as I don't scale os/DE UI above 100% often.
Comment 3 Buovjaga 2019-11-05 08:07:25 UTC
Unfortunately, both Roman and myself get nonsensical results when bibisecting this!
Comment 4 Xisco Faulí 2019-11-05 15:24:25 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2019-11-06 11:16:13 UTC
oh wait, my bisection was for bug 128593, not for this one...
Comment 6 Aron Budea 2019-11-16 07:36:28 UTC
(In reply to Buovjaga from comment #3)
> Unfortunately, both Roman and myself get nonsensical results when
> bibisecting this!
Sharing those nonsensical results might still be helpful, as an indication.
Like this one: https://cgit.freedesktop.org/libreoffice/core/log/?id=d4ad516bc0607a1d84451dd3dc8811a4f801fa4c
Comment 7 Roman Kuznetsov 2019-11-23 21:38:29 UTC
(In reply to Aron Budea from comment #6)
> (In reply to Buovjaga from comment #3)
> > Unfortunately, both Roman and myself get nonsensical results when
> > bibisecting this!
> Sharing those nonsensical results might still be helpful, as an indication.
> Like this one:
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?id=d4ad516bc0607a1d84451dd3dc8811a4f801fa4c

yep, I got this sha d4ad516bc0607a1d84451dd3dc8811a4f801fa4c five time=(
Comment 8 Jan-Marek Glogowski 2019-11-30 01:34:10 UTC
That bibisect result was really puzzling and it's actually correct. I also reproduced it :-)

I guess the bibisect repository is build incrementally without a "make clean", so it took a while, until soffice.bin needed to get linked again, which has caused this bug. Changing the text of a central header like include/osl/file.h* was the trigger for an almost full rebuild of LO.

The breaking commit is:

commit 7f791f431c79c6d0a156c4a2726a0dfc5ff40cc1
Author: Luboš Luňák <l.lunak@collabora.com>
Date:   Tue Oct 8 20:14:31 2019 +0200

    filter out the "Creating library" message from link.exe

The filtering command in the Makefile has an exit "${PIPESTATUS[0]}", which will exit the gb_LinkTarget__command macro after calling the linker. As a result the DeclareDPIAware.manifest isn't merged into the linked binaries, so Windows applies System DPI scaling. I first just checked soffice.exe, which was correct before and after the breaking commit. And it took me a while to realize, that the incremental build slowly lost its "dpiAware" manifest on all the executables and the problematic one is actually soffice.bin.

The proposed patch is: https://gerrit.libreoffice.org/#/c/84099/

I'm not really familiar with AWK scripting, so can currently just say, that the regexp based filtering still works for me in my German Windows locale.

Maybe the bug should be more important. OTOH bug 122218 isn't fixed since a year on MacOS, which - I guess - is some similar problem.
Comment 9 Mike Kaganski 2019-11-30 08:09:07 UTC
(In reply to Jan-Marek Glogowski from comment #8)
> I guess the bibisect repository is build incrementally without a "make
> clean", so it took a while, until soffice.bin needed to get linked again,
> which has caused this bug. Changing the text of a central header like
> include/osl/file.h* was the trigger for an almost full rebuild of LO.

... so there's a problem in bibisect commit creation, which needs a make clean each time, or at least when an .mk/autogen/configure change is detected ... :-)
Comment 10 Commit Notification 2019-12-04 19:24:59 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#128133 WIN don't exit after link-output filter

It will be available in 6.5.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 11 Buovjaga 2019-12-05 08:40:42 UTC
Verified, thanks!

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 9ab43aebad67383057d2cc3f754ce2193fa78b4e
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 12 V Stuart Foote 2019-12-05 14:11:34 UTC
Verified, looks to also have helped the Skia/Vulkan rendering.

On Windows 10 Home 64-bit en-US (1903) at 150% with
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 9ab43aebad67383057d2cc3f754ce2193fa78b4e
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 13 Commit Notification 2019-12-05 15:02:52 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

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

tdf#128133 WIN don't exit after link-output filter

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