Bug 107521 - Improve DirectWrite implementation font rendering on Windows
Summary: Improve DirectWrite implementation font rendering on Windows
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
: 112158 (view as bug list)
Depends on: 72944
Blocks: Font-Rendering DirectWrite 122457
  Show dependency treegraph
Reported: 2017-04-29 16:27 UTC by V Stuart Foote
Modified: 2021-05-03 14:13 UTC (History)
20 users (show)

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

A calc file useful to check scrolling speed deterioration in 5.4.1 (2.86 MB, application/vnd.oasis.opendocument.spreadsheet)
2017-09-14 09:19 UTC, Andy
Xcode instruments time/leak profile and BT (1.67 MB, application/x-zip-compressed)
2017-09-16 07:40 UTC, Telesto
rendering at 5.4.3. 1with fallback to GDI w/o OpenGL (85.26 KB, image/png)
2017-10-20 21:49 UTC, V Stuart Foote
rendering at 5.4.3. 1with OpenGL (87.26 KB, image/png)
2017-10-20 22:21 UTC, V Stuart Foote

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2017-04-29 16:27:22 UTC
So, at the OpenGL and the Default rendering both are DirectWrite based and now match output--but both are a bit roughly rendered. 

And we have the complaints of bug 106990 (seemingly from users of Default rendering, not previously exposed to quality of OpenGL rendering).

Is this a shortcoming with our DirectWrite implementation? Are we missing a control that leaves the ID2D1RenderTarget set to defaults and so is getting an unappealing rendering on Windows builds?

Should we be setting Rendering and Measurement modes from SetTextRenderingParams, and AntiAlais modes from SetTextAntialiasMode, to get more appealing rendering for both OpengGL and Default rendering.

And would implementing IDWriteFontFace::GetRecommendedRenderingMode be helpful to add to the font handling?

Not a dev but the DirectWrite documentation seems to suggest we are missing something.


IDWriteRenderingParams interface

Rendering Mode Win8 and earlier
Rendering Mode Win8.1 and on

Comment 1 V Stuart Foote 2017-07-06 14:18:16 UTC
For bug 106990 Tomaž has pushed this...



It is a good start, but think winlayout could use more love still as we move away from Windows GDI rendering at 6.0. 

XP (and Vista) are done, so an opportunity now to fully implement DirectWrite based CPU and GPU Hardware rendering. And likewise provide more reliable support for OpenGL rendering?
Comment 2 Tomaz Vajngerl 2017-07-06 15:09:40 UTC
A full switch would probably require that we move to D2D for all rendering and we still use the old GDI mostly and GDI+ in some cases. :)
Comment 3 V Stuart Foote 2017-07-06 15:43:30 UTC
(In reply to Tomaz Vajngerl from comment #2)
> A full switch would probably require that we move to D2D for all rendering
> and we still use the old GDI mostly and GDI+ in some cases. :)

Right and that is why--while issues like bug 106990 can be corrected--it seems we are just kicking it down the road by staying bound to GDI.

We've cut off XP and Vista at 5.4, and now have HarfBuzz in place, so going forward couldn't/shouldn't we move to a more complete implementation of DirectWrite/D2D?  And wouldn't that also give us better foundation for OpenGL support?

IIUC Win7 might require some hacking, but 8, 8.1 and 10+ are going to behave better for the Windows builds.
Comment 4 Michael Meeks 2017-07-06 16:15:40 UTC
Well - almost certainly we should switch to using freetype everywhere we can for text rendering - although I guess for Windows (which IIRC has no PDF based printer meta-file API) that means we would still need to use DirectWrite for the GDI based printing logic - unless we implement some grim XPS generator to match our PDF export that we could use for this =(
Comment 5 Khaled Hosny 2017-07-07 09:30:07 UTC
pdfium has some sort of code to convert PDF to metafile for printing and Mozilla seems to be considering using it for printing PDF on Windows. Not sure how good is it, but since we have pdfium already that would be one way to move our Windows printing code to PDF and may be finally unifying all platforms on PDF and sorting the printing mess. I’m not volunteering though.
Comment 6 Khaled Hosny 2017-07-07 09:33:30 UTC
Chrome also is starting to use FreeType partially on Windows and Mac to support the new variable fons format on Old versions of these systems that do not support them. So there is a precedent.
Comment 7 V Stuart Foote 2017-07-20 23:50:49 UTC
@Tomaž, *

Looks good, but are we immediately imposing technical debt with 


by keeping the pre-Windows 8 DirectWrite2D enumeration/syntax? [1]

At this point having pulled the plug on XP and Vista, should we push forward at 6.0 and instead set the minimum supported Windows OS to 7 SP1 with "Platform update (MS KB2670838)" [2] applied and supporting use of the "new" DWRITE enumeration/syntax and DirectX 11.1? [3].

Guess we have to keep the old enumeration/syntax for 5.4, and backport to 5.3, but would this help for eventualy moving rendering away from GDI, and also for refining OpenGL rendering?


[1] https://msdn.microsoft.com/en-us/library/windows/desktop/jj710196(v=vs.85).aspx

[2] https://support.microsoft.com/en-us/help/2670838/platform-update-for-windows-7-sp1-and-windows-server-2008-r2-sp1

[3] https://msdn.microsoft.com/en-us/library/windows/desktop/dd368118(v=vs.85).aspx
Comment 8 Aron Budea 2017-07-21 04:43:31 UTC
(In reply to V Stuart Foote from comment #7)
> At this point having pulled the plug on XP and Vista, should we push forward
> at 6.0 and instead set the minimum supported Windows OS to 7 SP1 with
> "Platform update (MS KB2670838)" [2] applied and supporting use of the "new"
> DWRITE enumeration/syntax and DirectX 11.1? [3].

I'd personally be all for this, just because it's more modern/future-proof, yet only requires an update in Win7 (the update itself is from 2013, so it's reasonable to expect systems to have it).

My questions:
- What happens if someone tries to run such an application on a Win7 without platform update? (I guess this could be tested)
- Is it possible to show an error dialog with meaningful information in that case? (eg. This application requires MS KB2670838 to run, update your system and try again.)
Comment 9 Tomaz Vajngerl 2017-07-21 06:59:09 UTC
Well DWRITE_RENDERING_MODE_GDI_CLASSIC is just renamed DWRITE_RENDERING_MODE_CLEARTYPE_GDI_CLASSIC so considering MS needs to have both for backwards compatibility is really doesn't matter which one we use. Unless they want to drop it, but I doubt they will do it anytime soon. I generally don't really care now.
Comment 10 Buovjaga 2017-09-10 12:54:33 UTC
*** Bug 112158 has been marked as a duplicate of this bug. ***
Comment 11 V Stuart Foote 2017-09-11 13:40:04 UTC
So, in addition to DirectWrite Direct2D rendering quality, there is also a noticeable performance impact from refactored font handling at 5.3 on Windows builds. 

Rendering multiple text objects--especially cells in a Calc sheet when scrolling or resizing [1][2]--has slowed with default HA or CPU only rendering, though still reasonable with OpenGL.

Likely requires additional font caching of some kind.

{1][2] bug 107770 and bug 109220
Comment 12 Andy 2017-09-14 08:47:35 UTC
Yes I wanted to confirm the problem. After filing bug 106990, and since nothing was changing about it, I gave up hopes and decided to settle for the ugly rendering for the moment, switching to
Then I discovered that cell rendering in Calc, which is the app I use the most, is now slowed down very drastically.
What is worse, though, is the fact that it seems to depend heavily on how much data are on the cells shown on the screen - while an empty or almost empty sheet still behaves in a barely acceptable speed, when you have large amounts of data the performance gets worse very rapidly.
It is easy to check, just fill some 20 columns x 1000 rows with any data, formula or numbers does not matter - and then scroll it, for example with the page down key!
While with 5.3.1 and previous releases this was speedy and handy, moving you around at a rate of 8-10 pages per second, it is now 5 to 6 times slower. But what is worse is that as soon as you keep pressing the key (or clicking the mouse button) for a little longer so that the buffer is filled (now yoiu need just a few seconds, since operation is so slow), the sheet will start moving for along time after you stop pressing the key, and you have to wait for all the unwanted scrolling for long times (since scrolling is terribly slow!!). You can imagine being around row 5000, you would like to go back to row 4000, you click page up for two seconds, the scrolling up starts, you deperss the PGD keys when you see row 4000 but at that point the scrolling is going on and there is nothing you can do except sit and wait. If you are unlucky, this will stop only after having reached the top of the sheet , leaving you more far away from row 4000 than before!
At present, in a calc file with a considerable amount of data, the only reliable and fast way to move around a sheet is to drag the "pointer bar" (i.e. the part that can be dragged) in the scroll bar with the mouse - which is easy and good when you sheet have little data, but is a difficult and painstaking exercise when you have some thousand rows. Otherwise, you will have to always keep in mind that you NEED to avoid pressing anything  - keys of mouse - for more than a second to avoid endless unwanted scrolling.
If one - like me - uses CALC to manage some data and has to be quick on the job, this problems makes downgrading again to 5.3 a reasonable option - and in fact I am sadly considering it.
If the behaviuour described is not clear, I can make a video capture of the screen; but it is actually very easy to check this problem
Comment 13 Andy 2017-09-14 09:03:22 UTC
I have now checked and scrolling speed in calc on 5.3.1 and 5.4.1 with a reisesoft parallel installation. Unfortunately, the difference is HUGE. Really two different planets, so to speak.
For my daily work, alas, I am downgrading again to 5.3.1...
Comment 14 Michael Meeks 2017-09-14 09:11:07 UTC
I poked the Mozilla guys to see if they have a solution for printing on Windows that will let us use freetype ~everywhere - no reply (yet) =) perhaps I should chase the Chrome-ites instead ...
Comment 15 Andy 2017-09-14 09:18:55 UTC
Sorry, a new update to just give you some facts. I have been making some comparisons between 5.3.1 and 5.4.1.
Using the attached calc file, "scroll speed experiment", which contains 5000 rows of random data, go to the bottom right of the sheet that contains the numbers. Then, use the page up key to scroll up to the top of the sheet. Keep the key pressed until you reach cell A1.
I previously wrote that 5.4.1 was "5 to 6 times slower"...

Unfortunately this is much worse:

on my core i5 intel notebook, 5.3.1 did this in 7.62 seconds;

5.4.1 crawled to A1 cell in no less than 100.33 secs!!

Therefore, 5.4.1 was about 13 THIRTEEN times slower.

Try this for yourself, I am curious to know about other PCs performances.
Comment 16 Andy 2017-09-14 09:19:47 UTC
Created attachment 136236 [details]
A calc file useful to check scrolling speed deterioration in 5.4.1
Comment 17 Andy 2017-09-14 09:20:57 UTC
Finally: the difference with openGl is barely noticeable on my PC - maybe this is better on other machines
Comment 18 Telesto 2017-09-16 07:40:54 UTC
Created attachment 136279 [details]
Xcode instruments time/leak profile and BT

(In reply to V Stuart Foote from comment #11)
> Rendering multiple text objects--especially cells in a Calc sheet when
> scrolling or resizing [1][2]--has slowed with default HA or CPU only
> rendering, though still reasonable with OpenGL.
> Likely requires additional font caching of some kind.

Not sure if this is the read thread, but the slow scrolling problem seems to be related to Harfbuzz (I would say). On MacOS at least. Reference_table(hb_face_t*, unsigned int, void*) is leaking a little bit (nearly not to mention) and consuming around 20% of the CPU time. I attached a few screenshots and a BT. Based on bug 108574)

Note: there is new version of Harfbuzz available (1.5.1). Last bump was to 1.4.8 (bug 109142).
Comment 19 Timur 2017-10-04 08:49:21 UTC
Nice example: attachment 135045 [details] from Bug 110794 that I closed as WFM. 
Simple test is to resize down LO window to 1/4 of size and then maximize and than again. 5.2.7 somewhat slow, 5.3 very slow, 5.3.7 reverted.
Comment 20 V Stuart Foote 2017-10-20 21:49:00 UTC
Created attachment 137169 [details]
rendering at 5.4.3. 1with  fallback to GDI w/o OpenGL
Comment 21 V Stuart Foote 2017-10-20 22:21:31 UTC
Created attachment 137171 [details]
rendering at 5.4.3. 1with OpenGL

@Tomaž, Michael, Khaled, *

Attached screen clips from the Windows 64-bit build (from a 1920x1200 dpi monitor) showing Start Panel and the About dialog. 

One is with GDI fallback from DirectWrite and Direct2D, the other with OpenGL and DirectWrite Direct2D rendering.

Accept that moving all rendering on Windows to Direct2D, or even FreeType, along with floating point positioning (bug 103322) is a future refactoring. 

But, can we do anything with the render mode now to clear up font rendering with OpenGL?

Would setting fixed rendering mode and anti alaising:


be a better DirectWrite Direct2D rendering match to the GDI rendering that folks seem to prefer, and keeps folks away from using OpenGL?
Comment 22 Petr Vones 2017-11-03 19:00:19 UTC
FYI the broken font anti-aliasing rendering (original Bug 112158) is fixed in for me. Thanks.
Comment 23 QA Administrators 2019-01-25 03:49:09 UTC Comment hidden (obsolete)
Comment 24 V Stuart Foote 2019-06-02 16:34:07 UTC
(In reply to QA Administrators from comment #23)
issue remains, the Direct Write D2D implementation needs more work, or FreeType replacment. With dependency in either case on bug 103322