Apache OpenOffice (AOO) Bugzilla – Issue 112730
graphite: slow performance with Graphite fonts in large docs
Last modified: 2017-05-20 10:22:39 UTC
Large files using Graphite fonts can be slow to render, especially at low zoom levels with lots of pages on screen. Following feedback from Roy Dalpra, the attached patch gives some improvement by addressing the following issues: - includes an upstream fix for uninitialized variables, which affected performance - stores the Segment advance after the first call, since Graphite doesn't cache it in the Segment and it is expensive to compute - increases the size of the OOo cache of Graphite segments and makes it configurable with an environment variable - improves caching of GlyphMetrics on both Windows and Linux, since these are expensive to compute - turns on dumb rendering in case Graphite fails to read the Graphite tables correctly, so at least the user sees something - changes the OOo GrFontHasher class to call the implementation specific UniqueCacheInfo methods which are more efficient that the gr::Font base class implementation. It was originally hoped to include these changes with the 2.4 release of Graphite, but since that has been delayed I've created this issue now. Graphite performance is still not as good as it could be, partly because Graphite was originally designed to layout entire paragraphs not lots of individual runs as OpenOffice does. There is currently an effort underway to rewrite the core Graphite engine to be optimized for the kind of use case that OpenOffice uses. This will eventually include caching within the graphite engine itself which should be much more efficient than the current caching in the OOo integration layer. However, this is some months from completion, so I hope the attached patches will give some improvement in the mean time.
Created attachment 70244 [details] patch to vcl and graphite/makefile.mk
Created attachment 70245 [details] updated graphite patch
Graphite patch attached as separate attachment since patches of patches are hard to read.
I tested the patches against DEV300_m83 on Linux Ubuntu 10.04 (64bit) and Vista (32 bit). For some reason I can't change the version field to a more sensible value.
Thanks! Looks good to me. I created a CWS for it (http://hg.services.openoffice.org/cws/graphite03) which is based on the latest milestone (DEV300_m83). You could apply the changes there or I could do it, depending on your preference.
Thanks for committing the changes. I'll test the resulting builds soon. Are there more changes pending for this CWS?
I have nothing more planned at this stage. I was rather hoping these changes might be able to get into 3.3, since they are more bug fixes than an enhancement.
At this stage of OOo33 regular bugfixes do not make it into that release, only showstoppers etc. On the other hand looking at the "releases" mailing list the hurdle is still low. Get approval from UL or MD for this issue being an OOo33 showstopper and we can change the target to OOo33.
With a simple but large testdoc for graphite the slowness could be recreated. For some scenarios like scrolling the improvement was a factor of 2..3 (ratio of handstopped times), nice! Looking at the changes everything is high quality and I see no risks for other code not related to graphite, so an approval for OOo33 would be fine with me.
@sba: please verify in CWS graphite03
Adjusted target
Verified in CWS graphite03.