So, at 5.3.2.2 the OpenGL and the Default rendering both are DirectWrite based and now match output--but both are a bit roughly rendered. And we have the complaints of bug 106990 (seemingly from users of Default rendering, not previously exposed to quality of OpenGL rendering). Is this a shortcoming with our DirectWrite implementation? Are we missing a control that leaves the ID2D1RenderTarget set to defaults and so is getting an unappealing rendering on Windows builds? Should we be setting Rendering and Measurement modes from SetTextRenderingParams, and AntiAlais modes from SetTextAntialiasMode, to get more appealing rendering for both OpengGL and Default rendering. And would implementing IDWriteFontFace::GetRecommendedRenderingMode be helpful to add to the font handling? Not a dev but the DirectWrite documentation seems to suggest we are missing something. =-refs-= ID2D1RenderTarget::SetTextRenderingParams https://msdn.microsoft.com/en-us/library/windows/desktop/dd316898(v=vs.85).aspx IDWriteRenderingParams interface https://msdn.microsoft.com/en-us/library/windows/desktop/dd371285(v=vs.85).aspx GetRenderingModes https://msdn.microsoft.com/en-us/library/windows/desktop/dd371300(v=vs.85).aspx Rendering Mode Win8 and earlier https://msdn.microsoft.com/en-us/library/windows/desktop/jj710196(v=vs.85).aspx Rendering Mode Win8.1 and on https://msdn.microsoft.com/en-us/library/windows/desktop/dd368118(v=vs.85).aspx AntiAlaisModes https://msdn.microsoft.com/en-us/library/windows/desktop/dd368170(v=vs.85).aspx
For bug 106990 Tomaž has pushed this... https://cgit.freedesktop.org/libreoffice/core/commit/?id=a5a3e82e99e7a60ec65c339dd0463af5c680cead https://gerrit.libreoffice.org/#/c/39602/ It is a good start, but think winlayout could use more love still as we move away from Windows GDI rendering at 6.0. XP (and Vista) are done, so an opportunity now to fully implement DirectWrite based CPU and GPU Hardware rendering. And likewise provide more reliable support for OpenGL rendering?
A full switch would probably require that we move to D2D for all rendering and we still use the old GDI mostly and GDI+ in some cases. :)
(In reply to Tomaz Vajngerl from comment #2) > A full switch would probably require that we move to D2D for all rendering > and we still use the old GDI mostly and GDI+ in some cases. :) Right and that is why--while issues like bug 106990 can be corrected--it seems we are just kicking it down the road by staying bound to GDI. We've cut off XP and Vista at 5.4, and now have HarfBuzz in place, so going forward couldn't/shouldn't we move to a more complete implementation of DirectWrite/D2D? And wouldn't that also give us better foundation for OpenGL support? IIUC Win7 might require some hacking, but 8, 8.1 and 10+ are going to behave better for the Windows builds.
Well - almost certainly we should switch to using freetype everywhere we can for text rendering - although I guess for Windows (which IIRC has no PDF based printer meta-file API) that means we would still need to use DirectWrite for the GDI based printing logic - unless we implement some grim XPS generator to match our PDF export that we could use for this =(
pdfium has some sort of code to convert PDF to metafile for printing and Mozilla seems to be considering using it for printing PDF on Windows. Not sure how good is it, but since we have pdfium already that would be one way to move our Windows printing code to PDF and may be finally unifying all platforms on PDF and sorting the printing mess. I’m not volunteering though.
Chrome also is starting to use FreeType partially on Windows and Mac to support the new variable fons format on Old versions of these systems that do not support them. So there is a precedent.
@Tomaž, * Looks good, but are we immediately imposing technical debt with http://cgit.freedesktop.org/libreoffice/core/commit/?id=3fdc41af6370a53f7db4e52104cfd3328ee40563 by keeping the pre-Windows 8 DirectWrite2D enumeration/syntax? [1] At this point having pulled the plug on XP and Vista, should we push forward at 6.0 and instead set the minimum supported Windows OS to 7 SP1 with "Platform update (MS KB2670838)" [2] applied and supporting use of the "new" DWRITE enumeration/syntax and DirectX 11.1? [3]. Guess we have to keep the old enumeration/syntax for 5.4, and backport to 5.3, but would this help for eventualy moving rendering away from GDI, and also for refining OpenGL rendering? =-ref-= [1] https://msdn.microsoft.com/en-us/library/windows/desktop/jj710196(v=vs.85).aspx [2] https://support.microsoft.com/en-us/help/2670838/platform-update-for-windows-7-sp1-and-windows-server-2008-r2-sp1 [3] https://msdn.microsoft.com/en-us/library/windows/desktop/dd368118(v=vs.85).aspx
(In reply to V Stuart Foote from comment #7) > At this point having pulled the plug on XP and Vista, should we push forward > at 6.0 and instead set the minimum supported Windows OS to 7 SP1 with > "Platform update (MS KB2670838)" [2] applied and supporting use of the "new" > DWRITE enumeration/syntax and DirectX 11.1? [3]. I'd personally be all for this, just because it's more modern/future-proof, yet only requires an update in Win7 (the update itself is from 2013, so it's reasonable to expect systems to have it). My questions: - What happens if someone tries to run such an application on a Win7 without platform update? (I guess this could be tested) - Is it possible to show an error dialog with meaningful information in that case? (eg. This application requires MS KB2670838 to run, update your system and try again.)
Well DWRITE_RENDERING_MODE_GDI_CLASSIC is just renamed DWRITE_RENDERING_MODE_CLEARTYPE_GDI_CLASSIC so considering MS needs to have both for backwards compatibility is really doesn't matter which one we use. Unless they want to drop it, but I doubt they will do it anytime soon. I generally don't really care now.
*** Bug 112158 has been marked as a duplicate of this bug. ***
So, in addition to DirectWrite Direct2D rendering quality, there is also a noticeable performance impact from refactored font handling at 5.3 on Windows builds. Rendering multiple text objects--especially cells in a Calc sheet when scrolling or resizing [1][2]--has slowed with default HA or CPU only rendering, though still reasonable with OpenGL. Likely requires additional font caching of some kind. =-ref-= {1][2] bug 107770 and bug 109220
Yes I wanted to confirm the problem. After filing bug 106990, and since nothing was changing about it, I gave up hopes and decided to settle for the ugly rendering for the moment, switching to 5.4.1.2 Then I discovered that cell rendering in Calc, which is the app I use the most, is now slowed down very drastically. What is worse, though, is the fact that it seems to depend heavily on how much data are on the cells shown on the screen - while an empty or almost empty sheet still behaves in a barely acceptable speed, when you have large amounts of data the performance gets worse very rapidly. It is easy to check, just fill some 20 columns x 1000 rows with any data, formula or numbers does not matter - and then scroll it, for example with the page down key! While with 5.3.1 and previous releases this was speedy and handy, moving you around at a rate of 8-10 pages per second, it is now 5 to 6 times slower. But what is worse is that as soon as you keep pressing the key (or clicking the mouse button) for a little longer so that the buffer is filled (now yoiu need just a few seconds, since operation is so slow), the sheet will start moving for along time after you stop pressing the key, and you have to wait for all the unwanted scrolling for long times (since scrolling is terribly slow!!). You can imagine being around row 5000, you would like to go back to row 4000, you click page up for two seconds, the scrolling up starts, you deperss the PGD keys when you see row 4000 but at that point the scrolling is going on and there is nothing you can do except sit and wait. If you are unlucky, this will stop only after having reached the top of the sheet , leaving you more far away from row 4000 than before! At present, in a calc file with a considerable amount of data, the only reliable and fast way to move around a sheet is to drag the "pointer bar" (i.e. the part that can be dragged) in the scroll bar with the mouse - which is easy and good when you sheet have little data, but is a difficult and painstaking exercise when you have some thousand rows. Otherwise, you will have to always keep in mind that you NEED to avoid pressing anything - keys of mouse - for more than a second to avoid endless unwanted scrolling. If one - like me - uses CALC to manage some data and has to be quick on the job, this problems makes downgrading again to 5.3 a reasonable option - and in fact I am sadly considering it. If the behaviuour described is not clear, I can make a video capture of the screen; but it is actually very easy to check this problem
I have now checked and scrolling speed in calc on 5.3.1 and 5.4.1 with a reisesoft parallel installation. Unfortunately, the difference is HUGE. Really two different planets, so to speak. For my daily work, alas, I am downgrading again to 5.3.1...
I poked the Mozilla guys to see if they have a solution for printing on Windows that will let us use freetype ~everywhere - no reply (yet) =) perhaps I should chase the Chrome-ites instead ...
Sorry, a new update to just give you some facts. I have been making some comparisons between 5.3.1 and 5.4.1. Using the attached calc file, "scroll speed experiment", which contains 5000 rows of random data, go to the bottom right of the sheet that contains the numbers. Then, use the page up key to scroll up to the top of the sheet. Keep the key pressed until you reach cell A1. I previously wrote that 5.4.1 was "5 to 6 times slower"... Unfortunately this is much worse: on my core i5 intel notebook, 5.3.1 did this in 7.62 seconds; 5.4.1 crawled to A1 cell in no less than 100.33 secs!! Therefore, 5.4.1 was about 13 THIRTEEN times slower. Try this for yourself, I am curious to know about other PCs performances.
Created attachment 136236 [details] A calc file useful to check scrolling speed deterioration in 5.4.1
Finally: the difference with openGl is barely noticeable on my PC - maybe this is better on other machines
Created attachment 136279 [details] Xcode instruments time/leak profile and BT (In reply to V Stuart Foote from comment #11) > Rendering multiple text objects--especially cells in a Calc sheet when > scrolling or resizing [1][2]--has slowed with default HA or CPU only > rendering, though still reasonable with OpenGL. > > Likely requires additional font caching of some kind. Not sure if this is the read thread, but the slow scrolling problem seems to be related to Harfbuzz (I would say). On MacOS at least. Reference_table(hb_face_t*, unsigned int, void*) is leaking a little bit (nearly not to mention) and consuming around 20% of the CPU time. I attached a few screenshots and a BT. Based on bug 108574) Note: there is new version of Harfbuzz available (1.5.1). Last bump was to 1.4.8 (bug 109142).
Nice example: attachment 135045 [details] from Bug 110794 that I closed as WFM. Simple test is to resize down LO window to 1/4 of size and then maximize and than again. 5.2.7 somewhat slow, 5.3 very slow, 5.3.7 reverted.
Created attachment 137169 [details] rendering at 5.4.3. 1with fallback to GDI w/o OpenGL
Created attachment 137171 [details] rendering at 5.4.3. 1with OpenGL @Tomaž, Michael, Khaled, * Attached screen clips from the 5.4.3.1 Windows 64-bit build (from a 1920x1200 dpi monitor) showing Start Panel and the About dialog. One is with GDI fallback from DirectWrite and Direct2D, the other with OpenGL and DirectWrite Direct2D rendering. Accept that moving all rendering on Windows to Direct2D, or even FreeType, along with floating point positioning (bug 103322) is a future refactoring. But, can we do anything with the render mode now to clear up font rendering with OpenGL? Would setting fixed rendering mode and anti alaising: DWRITE_RENDERING_MODE_CLEARTYPE_GDI_NATURAL D2D1_TEXT_ANTIALIAS_MODE_GRAYSCALE be a better DirectWrite Direct2D rendering match to the GDI rendering that folks seem to prefer, and keeps folks away from using OpenGL?
FYI the broken font anti-aliasing rendering (original Bug 112158) is fixed in 5.3.7.2 for me. Thanks.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #23) issue remains, the Direct Write D2D implementation needs more work, or FreeType replacment. With dependency in either case on bug 103322
(In reply to V Stuart Foote from comment #24) > (In reply to QA Administrators from comment #23) > issue remains, the Direct Write D2D implementation needs more work, or > FreeType replacment. With dependency in either case on bug 103322 V Stuart Foote, could you retest it now yourself in latest dev build?
(In reply to Roman Kuznetsov from comment #25) > > V Stuart Foote, could you retest it now yourself in latest dev build? Luboš purged most of the OpenGL related code as Skia lib based rendering was implemented. And Caolán, Chris and Khaled have done a fair bit of refactoring for winlayout and sallayout with end result that checking side-by-side on current Windows build master the Skia rendering (raster or Vulkan accelerated) antialiasing is now bit for bit identical with the GDI+ "default" vcl rendering. And where we seem to be using more of the DirectWrite 2D functions for the GDI+ paths as well. So, I'm OK closing this WFM as the potential for FreeType everywhere seems kind of unlikely to ever occur.