Bug Hunting Session
Bug 104242 - Temporarily remove OpenGL setting as default rendering for Windows builds
Summary: Temporarily remove OpenGL setting as default rendering for Windows builds
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta1
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Font-Rendering VCL-OpenGL HarfBuzz-regressions
  Show dependency treegraph
 
Reported: 2016-11-28 23:51 UTC by V Stuart Foote
Modified: 2016-12-21 21:08 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
sample various combining codepoints including diacritics (15.62 KB, application/vnd.oasis.opendocument.text)
2016-12-02 15:51 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-11-28 23:51:11 UTC
Description:
With the new HarfBuzz layout engine in place for 5.3.0 it seems text layout with OpenGL rendering on Windows is adversely affected by shortcomings of our DirectWrite implementation.

We have text layout parity with the Linux and OS X builds by using on GDI rendering for default rendering--down side is that the quality of the GDI sub-pixel rendering has been reduced with elimination of the DirectWrite calls. 

So the default rendering will look a little rough on screen compared to DirectWrite with OpenGL but the layout is more reliable.

Would suggest that until DirectWrite support for OpenGL rendering can be reworked--it would probably be best to drop OpenGL rendering as the default on the Windows builds the same as the Linux builds.

Steps to Reproduce:
na

Actual Results:  
na

Expected Results:
na


Reproducible: Always

User Profile Reset: Yes

Additional Info:
@Khaled gave up on the DirectWrite OpenGL and fell back to GDI where layout is now much improved. The layout with DirectWrite OpenGL rendering has continuing issues many predating the HarfBuzz engine that can't be corrected.

Suggests that the default GDI rendering would for the time being be a better default on Windows.

=-ref-=

https://gerrit.libreoffice.org/#/c/30868/




User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Comment 1 V Stuart Foote 2016-11-29 00:14:18 UTC
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?
Comment 2 Michael Meeks 2016-11-29 10:01:09 UTC
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.
Comment 3 tommy27 2016-11-29 10:54:04 UTC Comment hidden (off-topic)
Comment 4 Buovjaga 2016-11-29 11:06:59 UTC Comment hidden (off-topic)
Comment 5 V Stuart Foote 2016-11-29 14:47:48 UTC
(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.
Comment 6 Volga 2016-12-01 16:00:03 UTC
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.
Comment 7 Volga 2016-12-02 03:09:33 UTC
Also, wen can try to implenment using DirectWrite to render text without OGL.
Comment 8 V Stuart Foote 2016-12-02 13:35:18 UTC
(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.
Comment 9 martin_hosken 2016-12-02 13:54:02 UTC
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?
Comment 10 V Stuart Foote 2016-12-02 15:51:10 UTC
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.
Comment 11 Volga 2016-12-03 04:15:37 UTC
(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.
Comment 12 Michael Meeks 2016-12-03 10:29:55 UTC
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 ;-)
Comment 13 Khaled Hosny 2016-12-03 21:32:05 UTC
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.
Comment 14 Michael Meeks 2016-12-05 09:13:35 UTC
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.
Comment 15 Volga 2016-12-05 10:10:14 UTC
I have found BabelPad have an option to switch the engine for anti-aliasing, how does it work, is it helpful for this?
Comment 16 Volga 2016-12-05 14:36:17 UTC
(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
Comment 17 V Stuart Foote 2016-12-05 18:38:20 UTC
(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
Comment 18 Michael Meeks 2016-12-05 20:21:56 UTC
> 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.
Comment 19 Volga 2016-12-06 04:30:47 UTC
(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.
Comment 20 Khaled Hosny 2016-12-06 13:43:27 UTC
(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.
Comment 21 Volga 2016-12-07 04:09:17 UTC
(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.
Comment 22 Volga 2016-12-11 09:26:01 UTC
(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.
Comment 23 V Stuart Foote 2016-12-21 06:12:02 UTC
Going to close this. Things with OpenGL are on track.