Issue 112730

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.