Bug Hunting Session
Bug 107090 - Text is poorly rendered to presentation mode canvas with default rendering and "Use hardware acceleration" enabled (OpenGL and CPU only rendering is correct) (DirectWrite)
Summary: Text is poorly rendered to presentation mode canvas with default rendering an...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.3.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 106977 108236 109191 111681 112329 112588 113068 113933 113957 (view as bug list)
Depends on:
Blocks: Font-Rendering Textbox DirectWrite DirectWrite-Regression
  Show dependency treegraph
 
Reported: 2017-04-11 11:18 UTC by Volga
Modified: 2017-11-23 06:23 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (78.13 KB, image/png)
2017-04-11 11:22 UTC, Volga
Details
Screenshot 2 (71.15 KB, image/png)
2017-04-11 11:24 UTC, Volga
Details
two text boxes on presentation one rotated (13.38 KB, application/vnd.oasis.opendocument.presentation)
2017-07-07 18:40 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2017-04-11 11:18:03 UTC
Description:
When I play a slide show with LibreOffice 5.3.2.2, I found texts are rendered like bitmap images.

Steps to Reproduce:
1. Download & open a file from https://wiki.documentfoundation.org/File:Final-libreofficeintro.odp
2. Open with LibreOffice
3. Playing slide show

Actual Results:  
All the texts are rendered like bitmap images in full screen mode.

Expected Results:
While playing a slide show, texts in presentation file should be always rendered after they are scaled.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Volga 2017-04-11 11:22:32 UTC
Created attachment 132469 [details]
Screenshot

This is taken from first time when I see the problem, I haven’t enabled OpenGL.

Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: CL
Comment 2 Volga 2017-04-11 11:24:31 UTC
Created attachment 132470 [details]
Screenshot 2

Second screenshot after I enabled OpenGL.

Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: CL
Comment 3 V Stuart Foote 2017-04-11 14:02:01 UTC
Confirmed on Windows 10 Pro 64-bit en-US with nVidia GPU (drvr 21.21.13.7653) and
Version: 5.4.0.0.alpha0+
Build ID: 2f7b05988e6853ddac68b614e9d83e05af08bc0f
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-04-08_00:27:58
Locale: en-US (en_US); Calc: CL

and with

Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

OpenGL rendering is very clean, while Hardware acceleration (with/without anti-alaising) is pixelated, and strangely CPU only rendering is acceptable (with/without anti-alaising).

Believe this was the other facet of bug 106990 (https://bugs.documentfoundation.org/show_bug.cgi?id=106990#c15)

So moving to more DriectWrite calls from GDI is affecting the Presentation canvas. 

Just weird that the Hardware acceleration is different from the CPU only rendering--it does happen in other places (i.e. for printing EMF/WMF/SVM images in bug 104252) but this was unexpected.
Comment 4 V Stuart Foote 2017-04-11 21:09:54 UTC
Fired up Windows 7 sp1 32-bit VMWare VM with
Version: 5.3.2.2
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

With Default rendering and GPU Hardware acceleration--text rendered to the presentation canvas is badly shaped--very low resolution.  But on the same VM if Tools -> Options -> View "Use hardware acceleration" is unchecked the GPU only text rendered to the presentation canvas is clean.
Comment 5 V Stuart Foote 2017-04-12 01:00:11 UTC
adjusting summary...
Comment 6 Aron Budea 2017-04-14 00:21:38 UTC Comment hidden (bibisection)
Comment 7 Aron Budea 2017-04-14 00:23:03 UTC
Bibisection points to the following commit.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=3d456dfa6637c6c3ebe7a21f1f1a5b05039cee2a
author		Khaled Hosny <khaledhosny@eglug.org>	2016-10-28 02:19:46 (GMT)
committer	Khaled Hosny <khaledhosny@eglug.org>	2016-10-28 19:22:54 (GMT)

"tdf#98879: Fix vertical text on Windows for the new layout"
Comment 8 Khaled Hosny 2017-04-14 00:27:49 UTC
Not a HarfBuzz regression, the DirectWrite code that is now used in more places existed for quite sometime now.
Comment 9 Volga 2017-04-26 04:04:25 UTC
It seems to me that there is no effort for this when I try LibO 5.3.3.1.

Version: 5.3.3.1 (x64)
Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: group
Comment 10 V Stuart Foote 2017-04-28 22:29:29 UTC
Here is a weird rub to this.

If I add a text block, not only does it get pixelated when the "Use hardware acceleration" is enabled--but if I apply rotation to the text block it disappears in presentation mode!  But displays cleanly with CPU only or with OpenGL.

It came in between 5.3.1.2 and 5.3.2.1 so

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e80a0e0fd1875e1696614d24c32df0f95f03deb2..7f6693c08cc110b9721245fc4bd4f1712e0c086c

So, it includes https://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91 

Is something amiss in the gdi/winlayout.cxx
Comment 11 V Stuart Foote 2017-05-05 04:06:13 UTC
(In reply to V Stuart Foote from comment #10)
> Here is a weird rub to this.
> 
> If I add a text block, not only does it get pixelated when the "Use hardware
> acceleration" is enabled--but if I apply rotation to the text block it
> disappears in presentation mode!  But displays cleanly with CPU only or with
> OpenGL.
> 

This is also affecting the slide transitions. OK with OpenGL rendering, OK with CPU only. But, set "Use hardware rendering" and the transition will be done on a low resolution rendering, or if a rotated text block--the transition will apply to  a blank slide. 

Tested on Windows 10 Pro 64-bit en-US with
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group
Comment 12 Andy 2017-05-22 11:37:10 UTC
hi, does anyone know if something has happened on this problem with release 5.4.0.0?
Thanks
Comment 13 Telesto 2017-05-22 13:12:59 UTC
(In reply to Andy from comment #12)
> hi, does anyone know if something has happened on this problem with release
> 5.4.0.0?
> Thanks

Still a repro with:
Version: 5.5.0.0.alpha0+
Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07
Locale: nl-NL (nl_NL); Calc: CL
Comment 14 V Stuart Foote 2017-07-07 18:40:50 UTC
Created attachment 134533 [details]
two text boxes on presentation one rotated

Tomaž's work on DirectWrite [1] for bug 106990 have not corrected this issue. 

Attaching a single slide presentation file with two text boxes. Start the presentation and notice behavior of canvas for the rotated text box with Hardware acceleration enabled.  Likewise with OpenGL or just CPU rendering.

=-ref-=

[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=a5a3e82e99e7a60ec65c339dd0463af5c680cead

Testing Windows 8.1 Ent 64-bit en-US with
Version: 6.0.0.0.alpha0+
Build ID: 7ab9f12b57b1cb25b8b29f8bcbf006968db6b679
CPU threads: 8; OS: Windows 6.29; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-07_05:27:37
Locale: en-US (en_US); Calc: CL
Comment 15 V Stuart Foote 2017-08-11 13:06:39 UTC
*** Bug 111681 has been marked as a duplicate of this bug. ***
Comment 16 V Stuart Foote 2017-08-18 12:47:31 UTC
@Armin, * 

Related to https://bugs.documentfoundation.org/show_bug.cgi?id=104252#c32 is the canvas used for a slide's presentation mode pushed to EMF+, or is it SVM?

Is the issue here of HW accelerated--non OpenGL rendering--also going to be the same "Canvas direct renderer"  with presentation mode rendering of the slides, and when composing the transition effects for each? 

It is just weird that CPU only and OpenGL composition are fine, but HW Accelerated rendering of the slide's presentation mode canvas gets mangled.
Comment 17 Michael Meeks 2017-08-21 05:07:08 UTC
Arguably we should drop the alternative / direct-x acceleration, and just use OGL acceleration here via. the VCL canvas backend but ... ;-) controversial of course.
Comment 18 Armin Le Grand 2017-08-22 13:48:45 UTC
@V Stuart Foote: Has nothing to do with each other except that it uses Canvas for rendering. Until today Slideshow uses Metafile to transport graphic info - I wanted to change that to primitives (all info is there, Draw/Impress is completely on primitives) but was interrupted hard at that time, sigh.
It could be changed to primitive rendering any time - would be better for handing over anyways, primitives are UNO API objects. Together with a primitive renderer per system that uses HW acc directly (which also can be used in apps editviews display then) would be perfect.
The current primitive renderers render to vcl - that was the general and fallback implementation for primitive redering, pure renderers for e.g. OpenGL/DirectDraw or whatever would be possible anytime. From my POV that would be the better way, instead of putting more and more stuff 'below' vcl. Just my 2ct...
Comment 19 V Stuart Foote 2017-09-01 15:35:57 UTC
*** Bug 109191 has been marked as a duplicate of this bug. ***
Comment 20 Walter Cheuk 2017-09-13 06:08:13 UTC
Hi, I use Intel HD Graphics also has this problem. Would you please just disable the 'hardware acceleration' by default in the next version? It's hard for average user to find a solution for this.
Comment 21 Aron Budea 2017-09-13 09:16:43 UTC
*** Bug 112329 has been marked as a duplicate of this bug. ***
Comment 22 V Stuart Foote 2017-09-23 14:01:34 UTC
*** Bug 112588 has been marked as a duplicate of this bug. ***
Comment 23 Jacques Guilleron 2017-09-27 14:01:57 UTC
*** Bug 106977 has been marked as a duplicate of this bug. ***
Comment 24 Telesto 2017-10-03 17:42:15 UTC
No repro with
Version: 5.3.7.0.0+
Build ID: 8580472270972733cda7fa6ecf23db73359d30bb
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-TDF, Branch:libreoffice-5-3, Time: 2017-10-02_13:08:01
Locale: nl-NL (nl_NL); Calc: CL

Ugly font rendering & rotated text missing in Prestation mode with:
Version: 6.0.0.0.alpha0+
Build ID: f50bf3c5225b49b3c6f77f882e35305e5dc5ccd3
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-03_03:54:36
Locale: nl-NL (nl_NL); Calc: CL

=-ref-=
http://dev-builds.libreoffice.org/daily/libreoffice-5-3/
Comment 25 V Stuart Foote 2017-10-03 17:59:42 UTC
In an interesting effect, the GDI patch just applied against a 5.3.7 release-- tdf#112486 Do not force GDI in no OpenGL, restores presentation canvas using HA rendering to same quality as OpenGL or CPU only rendering. 

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5440837e02dee8bc884e02be697bfd4def621d26&h=libreoffice-5-3

=-Testing-=
Windows 10 Ent 64-bit en-US with
Version: 5.3.7.0.0+ (x64)
Build ID: 149f28e9a5d66db18ffb36547b2ba394c303fc4d
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-3, Time: 2017-09-30_08:04:07
Locale: en-US (en_US); Calc: CL

=-ref-=
http://dev-builds.libreoffice.org/daily/libreoffice-5-3/
Comment 26 V Stuart Foote 2017-10-04 18:27:43 UTC
*** Bug 108236 has been marked as a duplicate of this bug. ***
Comment 27 V Stuart Foote 2017-10-04 18:34:32 UTC
Fixed in master/6.0, 5.4 and 5.3 by Xisco and Khaled for work on bug 112486 -- Do not force GDI in no OpenGL

With that correction, the presentation mode canvas with HA rendering is again crisply rendered.

Additional work on DirectWrite font handling may again affect this, but for now fixed.

=-ref-=

https://cgit.freedesktop.org/libreoffice/core/commit/?id=01f674a95ddec76dc4c8ecfccdca1773657e47cb

https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-4&id=2ed67ed55ad929eb9363a5c4e3c55b3ee857d984

https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-3&id=5440837e02dee8bc884e02be697bfd4def621d26
Comment 28 Xisco Faulí 2017-10-04 20:56:27 UTC
This is a problem in DirectWrite, thus it's not fixed. My commit only changes the behaviour to use GDI instead, as it was before. The plan is to move to DirectWrite at some point. Keeping it open.
Comment 29 V Stuart Foote 2017-10-04 21:10:52 UTC
@Xisco, issue as in the summary is corrected, fallback from non-OpenGL is rendered correctly again om presentation canvas when the HA is in use.

Yes there remains a need to resolve our DirectWrite font handling--but that is not _this_ bug which is corrected now in 5.3.7, for 5.4.3 when rolled and in master for 6.0.0 for the commits noted.

The impact on canvas composition with HA vs. CPU only rendering is an implementation issue as we move forward either with DireectWrite Direct2D, or more cross platform with a FreeType implementation.
Comment 30 V Stuart Foote 2017-10-04 21:17:10 UTC
*** Bug 108236 has been marked as a duplicate of this bug. ***
Comment 31 Xisco Faulí 2017-10-10 10:55:41 UTC
*** Bug 113010 has been marked as a duplicate of this bug. ***
Comment 32 V Stuart Foote 2017-10-12 21:19:30 UTC
*** Bug 113068 has been marked as a duplicate of this bug. ***
Comment 33 Xisco Faulí 2017-10-18 11:17:09 UTC
Currently there's no way to enable the DirectWrite from the UI, thus closing as
RESOLVED WORKSFORME
Comment 34 V Stuart Foote 2017-11-19 19:06:21 UTC
*** Bug 113933 has been marked as a duplicate of this bug. ***
Comment 35 V Stuart Foote 2017-11-23 06:23:56 UTC
*** Bug 113957 has been marked as a duplicate of this bug. ***