Issue 112730 - graphite: slow performance with Graphite fonts in large docs
Summary: graphite: slow performance with Graphite fonts in large docs
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: DEV300m83
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: stefan.baltzer
QA Contact: issues@gsl
Keywords: performance
Depends on:
Blocks: 108220 111112
  Show dependency tree
Reported: 2010-06-27 11:18 UTC by devel
Modified: 2017-05-20 10:22 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

patch to vcl and graphite/ (18.34 KB, patch)
2010-06-27 11:22 UTC, devel
no flags Details | Diff
updated graphite patch (90.92 KB, patch)
2010-06-27 11:23 UTC, devel
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description devel 2010-06-27 11:18:52 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

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.
Comment 1 devel 2010-06-27 11:22:43 UTC
Created attachment 70244 [details]
patch to vcl and graphite/
Comment 2 devel 2010-06-27 11:23:32 UTC
Created attachment 70245 [details]
updated graphite patch
Comment 3 devel 2010-06-27 11:25:14 UTC
Graphite patch attached as separate attachment since patches of patches are hard
to read.
Comment 4 devel 2010-06-27 11:32:55 UTC
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.
Comment 5 2010-06-28 09:30:24 UTC
Thanks! Looks good to me. I created a CWS for it ( 
which is based on the latest milestone (DEV300_m83). You could apply the changes there or I could do it, 
depending on your preference.
Comment 6 2010-06-29 14:11:17 UTC
Thanks for committing the changes. I'll test the resulting builds soon. Are there more changes pending for 
this CWS?
Comment 7 devel 2010-06-29 15:39:51 UTC
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.
Comment 8 2010-06-29 18:14:36 UTC
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.
Comment 9 2010-06-30 10:56:36 UTC
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.
Comment 10 2010-06-30 12:37:30 UTC
@sba: please verify in CWS graphite03
Comment 11 uwe.luebbers 2010-07-01 16:56:33 UTC
Adjusted target
Comment 12 stefan.baltzer 2010-07-06 15:30:51 UTC
Verified in CWS graphite03.