Kind of in a hard place here, achieved much of what the new HarfBuzz layout engine promised. But its cost on Windows has been spotty support using our DirectWrite and OpenGL rendering.

Khaled is not really able to resolve issues with the OpenGL rendering as he lacks the hardware support needed to develop for it.

IIRC while implementing OpengGL rendering it was decided to make it configure by default on the Windows builds (and catch poor GPU/driver OpenGL support with our blacklist mechanism) and fall back to default GDI+ rendering.

In finalizing the new layout engine Khaled has gutted the DirectWrite from the GDI rendering so it offers stable layout in all areas of the UI. 

Question is what to do about the OpenGL rendering that remains dependent on DirectWrite calls. Believe that until it can be fixed correctly, we would probably be better to not enable it by default on the Windows builds.

But only fair that the Devs more heavily invested in implementing OpenGL support (and likely having to fix it) should make the call.

Thoughts?

Moving away from DirectWrite sounds like going -horribly- backwards; there is no good physical font API prior to DirectWrite - so we will continue to encode rubbish font metrics into documents and create an ongoing support nightmare. I would strongly prefer to use eg. freetype everywhere than existing legacy GDI font rendering APIs.

This needs some serious thought, code reading, and ideally some better hardware for Khaled - which I'm working on.

(In reply to Michael Meeks from comment #2)
> Moving away from DirectWrite sounds like going -horribly- backwards...

Sorry, I was not suggesting we could abandon DirectWrite. I was suggesting that until we can improve our DirectWrite implementation--and ideally restore a GDI+ rendering--that the default rendering on Windows build should not be OpenGL when a user's hardware supports it.

IIUC at 5.3.0 with Default rendering on Windows, we've reverted to "legacy" GDI. The DirectWrite based GDI+ that was providing better sub-pixel rendering had to be dropped as our GDI+ implementation was not behaving well with HarfBuzz. Likewise misbehaving with HarfBuzz our OpenGL rendering remains DirectWrite dependent--but that can not be changed.

So the choice for users who have OpenGL capable hardware is between a less than perfect script layout with OpenGL rendering enabled, or a somewhat reduced font rendering quality with "default" rendering now missing better DirectWrite GDI+ sub-pixel rendering.  

What rendering should Windows configuration enable by default--Default or OpenGL?

Suspect at 5.3.0 we will be hearing quickly from users _without_ OpenGL capable hardware about losses in their text quality. Can't be avoided, and can't be corrected until we can improve our DirectWrite implementation.

I guess this can be done if we are still be affected by some annoying OpenGL related bugs before LibreOffice 5.3.0 stable release is released.

Also, wen can try to implenment using DirectWrite to render text without OGL.

(In reply to Volga from comment #7)
> Also, wen can try to implenment using DirectWrite to render text without OGL.

Well sure, that will ultimately need to happen anyhow. But much of the prior existing DirectWrite GDI+, Khaled had to strip away piece-by-piece for Windows GDI to get consistent cross-platform behavior with HarfBuzz, and why the DirectWrite OpenGL rendering is "less good" at 5.3.0 and on master. 

The GDI default rendering is now in pretty good shape and compares well cross platform.  But text rendering with OpenGL is lagging behind because DirectWrite implementation(s) for OpenGL and GDI+ both need to be improved.

Suggestion here is that until that happens we should not enable OpenGL rendering as default for any users on Windows. It would still be available as an option, just not the default.

The problem with reverting to GDI is that it is buggy when rendering diacritics. The only reason GDI rendering worked in the past was that the shaping and rendering were both done with Uniscribe. The whole reason we bust a gut to get DirectWrite working for non OpenGL was to work around the bug in ExtTextOut that is in Windows 8.1 and following that renders glyphs on the screen in the wrong place.

So I am concerned that shipping 5.3 calling GDI is a introducing a nasty regression against 5.2. I don't understand the reasoning that says: OpenGL is broken, so let's not use D2D at all. Whether we turn off OpenGL by default on Windows is neither here nor there, but using GDI ExtTextOut is a Bad Thing. Can we turn off OpenGL *and* use D2D?

Created attachment 129253 [details]
sample various combining codepoints including diacritics

(In reply to martin_hosken from comment #9)

Actually not sure we do any worse with GDI vs. GDI+ or OepnGL with DriectWrite. 

Compare the attached between a 5.2.3.3 build and 5.3.0beta1, or current master--font fallback is obviously now better handled, but the combining diacritics are composed at least as well as at 5.2.3 with Khaled's GDI implementation and HarfBuzz layout.

(In reply to martin_hosken from comment #9)
> So I am concerned that shipping 5.3 calling GDI is a introducing a nasty
> regression against 5.2. I don't understand the reasoning that says: OpenGL
> is broken, so let's not use D2D at all. Whether we turn off OpenGL by
> default on Windows is neither here nor there, but using GDI ExtTextOut is a
> Bad Thing. Can we turn off OpenGL *and* use D2D?

I have already created bug 101227 for this.

I think this is really a red-herring, where OpenGL issues are conflated with DirectWrite issues. Here is how I'd like us to proceed:

* We need to move to abandon GDI's ExtTextOut - it is a nightmare (as Martin says). This -may- cause some documents (which were relying on awful, undocumented, un-sustainable, Windows-only fallback behavior) to change rendering/layout -> c'est la vie; un-fixable.
    + I'd like to see us using DirectWrite -everywhere- by default GDI,
      GL etc. For Windows-XP - we have to use the legacy horrors here.

* From this point, with a real physical font-API we should be able to cache, and stamp glyphs as-now with OpenGL, which I'd like to retain as default for 5.3 if we can - lets at least leave it on through some of the bug fixing phase.

I think the OpenGL problems are likely to not be too horrific, but its hard for Khaled to test the hafbuzz changes against - so he is being shipped an OpenGL capable Windows laptop to try to help out there =)

Ultimately, wrt. OpenGL - we need to move to a cross-platform, accelerated API - and there is only one of these, and it it is not GDI+ or Direct2D ;-)

Switching to Freetype is an interesting idea, but IMHO unpractical. First we don’t use Freetype directly to render text on Linux, we use Cairo, so switching to Freetype without Cairo will require writing a good chunk of non-trivial code. The other issue is that, unlike text layout, people are very sensitive to font rendering and people on Windows will most likely scream very loudly if LibreOffice started rendering text differently than the system (same on Mac), and getting Freetype to emulate the Windows font rendering might not be even possible.

We probably want to switch to a cross-platform graphics library in the future and unify our graphics and text rendering like we did for text layout. Cairo is a good candidate since we already have working Cairo integration on Linux, but I hear that Cairo’s performance on Windows is not very optimal and its development slowed down considerably in the last years. Skia is another alternative, used by Chrome and Firefox, but we will need to write Skia integration from scratch which is not a small project.

I like the idea of Skia integration personally, but as you say it needs work. I'd like to kill this guy though:

> The other issue is that, unlike text layout, people are very sensitive
> to font rendering and people on Windows will most likely scream very loudly
> if LibreOffice started rendering text differently than the system

FWIW - we already did; we've done this for all releases with GL as default - which has not been using ClearType - and no screaming ;-) Also - Microsoft Office itself does not use the platform font rendering (except for (just parts) of its toolbar) - the body / document text is rendering grey-scale with no hinting - I -assume- to improve cross-platform document rendering ;-)

Re-using whatever code Cairo uses to drive freetype sounds sensible to me too (for the short-run), I've no problems with that. But I don't think we need to be overly worried about the platform font integration, and should be more worried about consistency I think.

I have found BabelPad have an option to switch the engine for anti-aliasing, how does it work, is it helpful for this?

(In reply to Volga from comment #15)
> I have found BabelPad have an option to switch the engine for anti-aliasing,
> how does it work, is it helpful for this?

BabelPad have this option on Fonts > Quality, which can switch font rendering enging, this is interesting.

=-ref-=
http://www.babelstone.co.uk/Software/BabelPad_Menu.html#Fonts

(In reply to Volga from comment #16)
> BabelPad have this option on Fonts > Quality, which can switch font
> rendering enging, this is interesting.

Checked with Andrew West, BableStone and he passed on that he is just using the values from Windows LOGFONT lfQuality, nothing exotic and nothing cross platform.

And so offers nothing more than would resolving the completeness of our DirectWrite D2Dwrite implementation for GDI+ and OpenGL rendering.

I'd assume we would be passing default CLEARTYPE_NATURAL_QUALITY to allow HarfBuzz layout to do what it needs to for positioning glyphs. 

=-refs-=
LOGFONT sturcts
https://msdn.microsoft.com/en-us/library/windows/desktop/dd145037(v=vs.85).aspx

General DirectWrite Intro
https://msdn.microsoft.com/en-us/library/windows/desktop/dd371554(v=vs.85).aspx

> Checked with Andrew West, BableStone and he passed on that he is just using the 
> values from Windows LOGFONT lfQuality, nothing exotic and nothing cross 
> platform.

The 'nothing cross-platform' is rather a problem; we need to move to a high quality, accelerated rendering API on every platform that provides -identical- text sizing, shaping and rendering. Ideally with sub-pixel positioning of course - but doing accelerated cleartype rendering is quite a tough problem, not least because whether cleartype works or not is based on what is behind the text, and how close adjacent strokes are: so it can't be pre-rendered, and glyph stamped ourselves.

ie. IMHO cleartype is a disaster waiting to happen for the goal of a cross-platform acceleration - at least, until we have a high quality GPU based glyph rendering - which (no doubt) is coming. This seems to be the conclusion of Microsoft too - they don't use ClearType in Office 2016. To some degree it is also orthogonal to the rendering technology - DirectWrite is excellent not because it (sometimes) puts colors around glyps ;-) but because you can actually ask it how wide a glyph is and it doesn't systematically lie through its teeth in ways that are extraordinarily hard to unwind.

(In reply to V Stuart Foote from comment #17)
> I'd assume we would be passing default CLEARTYPE_NATURAL_QUALITY to allow
> HarfBuzz layout to do what it needs to for positioning glyphs. 

I also assume passing ANTIALIASED_QUALITY would get better effect for playing slideshow.

(In reply to Michael Meeks from comment #14)
> I like the idea of Skia integration personally, but as you say it needs
> work. I'd like to kill this guy though:
> 
> > The other issue is that, unlike text layout, people are very sensitive
> > to font rendering and people on Windows will most likely scream very loudly
> > if LibreOffice started rendering text differently than the system
> 
> FWIW - we already did; we've done this for all releases with GL as default -
> which has not been using ClearType - and no screaming ;-) Also - Microsoft
> Office itself does not use the platform font rendering (except for (just
> parts) of its toolbar) - the body / document text is rendering grey-scale
> with no hinting - I -assume- to improve cross-platform document rendering ;-)

Interesting, didn’t realize that. Sure if we can pull such a change without major pushback, it would widen our options.

Lets see if we can get things moving in the short term with DirectWrite in the meantime.

(In reply to Michael Meeks from comment #18)
> ie. IMHO cleartype is a disaster waiting to happen for the goal of a
> cross-platform acceleration - at least, until we have a high quality GPU
> based glyph rendering - which (no doubt) is coming. This seems to be the
> conclusion of Microsoft too - they don't use ClearType in Office 2016. 

I also heard Chinese netizens trend to use MacType (which uses FreeType as beckend) to replace ClearType for screen rendering.

(In reply to Michael Meeks from comment #18)
> > Checked with Andrew West, BableStone and he passed on that he is just using the 
> > values from Windows LOGFONT lfQuality, nothing exotic and nothing cross 
> > platform.
> 
> The 'nothing cross-platform' is rather a problem; we need to move to a high
> quality, accelerated rendering API on every platform that provides
> -identical- text sizing, shaping and rendering. Ideally with sub-pixel
> positioning of course - but doing accelerated cleartype rendering is quite a
> tough problem, not least because whether cleartype works or not is based on
> what is behind the text, and how close adjacent strokes are: so it can't be
> pre-rendered, and glyph stamped ourselves.
> 
> ie. IMHO cleartype is a disaster waiting to happen for the goal of a
> cross-platform acceleration - at least, until we have a high quality GPU
> based glyph rendering - which (no doubt) is coming. This seems to be the
> conclusion of Microsoft too - they don't use ClearType in Office 2016. To
> some degree it is also orthogonal to the rendering technology - DirectWrite
> is excellent not because it (sometimes) puts colors around glyps ;-) but
> because you can actually ask it how wide a glyph is and it doesn't
> systematically lie through its teeth in ways that are extraordinarily hard
> to unwind.

I also remembered MS Office 2013 has different text rendering effect than system, especially for document and playing slideshow.

Going to close this. Things with OpenGL are on track.