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
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
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
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.
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.
adjusting summary...
Bibisected using repo bibisect-win32-5.3. 52fc4434554cb8bcbcc13469646a6ea5c99f77af is the first bad commit commit 52fc4434554cb8bcbcc13469646a6ea5c99f77af Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Oct 28 12:35:08 2016 -0700 source 3d456dfa6637c6c3ebe7a21f1f1a5b05039cee2a # bad: [a374222bc87bd9e75ea2f1ca45d189932a1967f8] source aa09fd58bd499a2a2c3a32c5f613892bad54076c # good: [48651d24832b96251b5475cc061d162d84b9a0e7] source 15f6a97d9f23124c19471b9d8dd38f14f53829b3 git bisect start 'a374222bc87bd9e75ea2f1ca45d189932a1967f8' '48651d24832b96251b5475cc061d162d84b9a0e7' # bad: [c86cb0d5c642ed8ee5c4397d7b06314bc41cfe61] source bf0a2303184d7fcbbfa4fbedbf9d2dd8cd83cf6b git bisect bad c86cb0d5c642ed8ee5c4397d7b06314bc41cfe61 # good: [cff6691975c05fa4f67e5507c2469ef29fb8b55a] source 03c7cfb6a680a483962d64d52c70ad5972a7b08b git bisect good cff6691975c05fa4f67e5507c2469ef29fb8b55a # bad: [1d7bd0768bbea17deb2b91113f18df598b32307a] source b297f7bbfed83f87398231740e910afe6ebfbb97 git bisect bad 1d7bd0768bbea17deb2b91113f18df598b32307a # bad: [4da51a5f484e764d720d661ec5ecb86c7dc999de] source 9fa6dadc4e1e75b2fd7b7360995c524fa7a5d40e git bisect bad 4da51a5f484e764d720d661ec5ecb86c7dc999de # bad: [e49204be86c2d84cce6c2abc5414245e537bb080] source ffed74ee5450e6f6dd63ad3db489ebdbaa13d5fd git bisect bad e49204be86c2d84cce6c2abc5414245e537bb080 # bad: [00dd407d4c3bc46a7b12e6e5f793b144d3e4029b] source 6d68b2bbc9e52f92f1af025f360553646c6a598a git bisect bad 00dd407d4c3bc46a7b12e6e5f793b144d3e4029b # bad: [d6527b6092b2d8b0729e3acd573e3936fdf0d5d4] source 87c518593de59dbf4c0f5f45c720b14a05aeca9e git bisect bad d6527b6092b2d8b0729e3acd573e3936fdf0d5d4 # good: [58dcb6af379f0acea7649ba126ca3f597c1bbd7e] source 56cc352d8229c16604f39a21bd77a05b422470f4 git bisect good 58dcb6af379f0acea7649ba126ca3f597c1bbd7e # bad: [52fc4434554cb8bcbcc13469646a6ea5c99f77af] source 3d456dfa6637c6c3ebe7a21f1f1a5b05039cee2a git bisect bad 52fc4434554cb8bcbcc13469646a6ea5c99f77af # good: [53e340478bb7254b92c1ca0c14639dfa1055ff46] source 25df5f2ac79c8b121282e8c0d6506b456b37f819 git bisect good 53e340478bb7254b92c1ca0c14639dfa1055ff46 # good: [ee5bfce110bfa45d6fc6bd1fafc19f45bff43fb7] source c0baab9aa80bfa49b753d2d598a4fbc71ceb656e git bisect good ee5bfce110bfa45d6fc6bd1fafc19f45bff43fb7 # first bad commit: [52fc4434554cb8bcbcc13469646a6ea5c99f77af] source 3d456dfa6637c6c3ebe7a21f1f1a5b05039cee2a
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"
Not a HarfBuzz regression, the DirectWrite code that is now used in more places existed for quite sometime now.
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
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
(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
hi, does anyone know if something has happened on this problem with release 5.4.0.0? Thanks
(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
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
*** Bug 111681 has been marked as a duplicate of this bug. ***
@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.
Arguably we should drop the alternative / direct-x acceleration, and just use OGL acceleration here via. the VCL canvas backend but ... ;-) controversial of course.
@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...
*** Bug 109191 has been marked as a duplicate of this bug. ***
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.
*** Bug 112329 has been marked as a duplicate of this bug. ***
*** Bug 112588 has been marked as a duplicate of this bug. ***
*** Bug 106977 has been marked as a duplicate of this bug. ***
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/
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/
*** Bug 108236 has been marked as a duplicate of this bug. ***
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
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.
@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.
*** Bug 113010 has been marked as a duplicate of this bug. ***
*** Bug 113068 has been marked as a duplicate of this bug. ***
Currently there's no way to enable the DirectWrite from the UI, thus closing as RESOLVED WORKSFORME
*** Bug 113933 has been marked as a duplicate of this bug. ***
*** Bug 113957 has been marked as a duplicate of this bug. ***