Font rendering has looked awful with GL enabled - since we've been converting cleartype to masks - when we should have been rendering in greyscale. That resulted in insufficiently dense anti-aliasing pixels around glyphs - giving something of an aliased look to text. Fixing this gives a big win to readability; screenshot to follow.
Created attachment 123192 [details] We move from left to right with a one-line fix.
fixes pushed to gerrit =)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a419ef186038e92f27ac5e201e231578867a66e9 tdf#98380 - opengl - get font anti-aliasing right. It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The simple grayscale rendering looks worse in laptops — while our GL rendering was too strong and looked aliased on the vertical axis, it had good contrast —, but anyway… Hopefully we will someday draw with DirectWrite/Direct2D (bug 91946).
*** Bug 97812 has been marked as a duplicate of this bug. ***
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c473d38885e74b5a48ccd54b1f3e30b01a710d2&h=libreoffice-5-1 tdf#98380 - opengl - get font anti-aliasing right. It will be available in 5.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 123447 [details] Windows font anti alaising with OpenGL after the 20160303 patch @Michael M., * I know this is a bit of a "whack-a-mole" chase for you, but think things with OpenGL anti-aliasing of Windows fonts are still a bit off the mark with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=a419ef186038e92f27ac5e201e231578867a66e9 See the attached ODG, left side are two info panels from the 20160303 TB39 build default above and OpenGL below. And on right are info panels from the 20160304 TB39 build--default remains clear but the OpenGL anti-alaising is a bit rough. Same poor AA effects across UI for all builds after 20160304. This is on Windows 8.1 Pro 64-bit en-US with nVidia Quadro K2000 (361.91 driver) Version: 5.2.0.0.alpha0+ Build ID: fee4fe8e589e101140d9b318ac757825bf836506 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-04_03:16:28 Locale: en-US (en_US) bisect to between the 20160303 and 20160304 builds (TB39) https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=7ccdb94e2c5774f924bf89b34387c7d41e2e4c30..fee4fe8e589e101140d9b318ac757825bf836506
Should note that this seems to only be affecting the UI menu and dialog elements that are using system default font--so on Windows 8.1 that is Segoe UI. Text on a document canvas assigned Segoe UI is rendered cleanly without the AA issues. So is this a Windows OS font smoothing collision with the OpenGL being applied to LibreOffice menus and dialogs? If so, any way to isolate menus and dialogs from the OpenGL wrapper?
Hi Stuart, I had a look at this; It is far from simple to have one font rendering method for the UI and another for the document. Potentially we would write some new shaders to have ClearType on arbitrary text backgrounds - although my hope is that glyphy provides a better direction for accelerated rendering of sub-pixel aligned text outlines. It seems to me that the help/about dialog suffers from relatively low contrast - which makes the text less distinct than it could be. That getting the AA right makes it look worse is mostly an artifact of us removing the original aliasing from the mangled ClearType outlines which gave higher contrast. There is also some font/size issue here - my Windows 7 / ClearType rendering does a horrible job of aliasing larger glyphs eg. tops of 'O's but of course is better for smaller ones on high contrast backgrounds - so any perfect solution would enable / disable this depending on size I think. We're on the right track - we should be rasterizing glpyhs, not just stamping them on the GPU; and ideally (as/when we get cross-platform harfbuzz) at sub-pixel resolution. I'm inclined to close this and open a new GPU rasterization bug.
@Michael, * On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ (x64) Build ID: 042f16a19e3d5f884759dae71264433b988df0e6 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-03-16_10:03:38 Locale: en-US (en_US) With todays TB62 build of master the new DirectWrite support for OpenGL rendering looks much cleaner. No longer seeing anti-alaising shaping glitches in the dialog or menus.