I don't use command line.
I don't use a configuration file.
Effect on embedded code?
From: Glenn Adams [mailto:gl...@skynav.com]
Sent: Tuesday, July 19, 2011 7:18 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: should complex script features be enabled or
FopFactory.setComplexScriptFeaturesEnabled(false)
On Wed, Jul 20, 2011 at 6:13 AM, Eric Douglas edoug...@blockhouse.comwrote:
**
I don't use command line.
I don't use a configuration file.
Effect on embedded code?
--
*From:* Glenn Adams
I'd enable it by default. I think that results in fewer questions and
performance freaks can always disable it if you can make it configurable.
On 19.07.2011 03:40:56 Glenn Adams wrote:
I'm adding a feature to allow enable/disable of complex script features
(bidi, complex char to glyph mapping)
Hi Glenn,
IMHO, the default setting should depend on how much it affects the
performances.
Can you give an approximative impact?
Le 19/07/2011 03:40, Glenn Adams a écrit :
I'm adding a feature to allow enable/disable of complex script features
(bidi, complex char to glyph mapping) at runtime,
Good call. You'll get more questions enabling it by default if most people
don't need it and it has a significant performance impact.
Why is this new version so much slower?
To my users, applications not crashing is the number one priority. Performance
is number two.
-Original
Taking the average of the best 3 out of 5 runs for a couple of the junit
tests, I get the following:
TRUNK CMPLX DIFF%
junit-basic 4.87s 4.92s 1.01%
junit-layout-standard36.34s36.72s 1.04%
In the case of junit-layout-standard,
On 07/19/2011 09:36 AM, Glenn Adams wrote:
So, I'd say that there is about a 1% decrease in speed performance
based on this data.
I doubt if users will even notice this, so this would argue for
enabling by default.
Agree. For a feature of this magnitude, 1% is not a huge hit, and
Hi Glenn,
We took a look at the complex scripts support, and a big chunk of the
code-base is in the fonts, and the layout tests don't cover fonts,
rendering etc. What are you finding for end-to-end performance? We
created a large latin only document and found about 50% increase in
time.
Mehdi
Hi Glenn,
What we did isn't very complex, a 2000-odd page document filled with
Loret ipsum... That's about it, the font used was ArialUnicodeMS.ttf
and was embedded in the PDF. The version was i18n.arabic@09c38b8b and
the major blocking point was in TTFFile.java readGDEF(in) readGSUB(in)
and
Hmm, that may not be a very representative example, since:
- Arial Unicode MS is one of the largest fonts (23MB, 50377 glyphs)
- read{GDEF,GSUB,GPOS} is a one-time event when reading the font
It would be useful for you to try:
- one page versus 2000 pages
- same but with another
You are right, the difference is not significant.
Enabled by default makes sense for me.
Le 19/07/2011 15:36, Glenn Adams a écrit :
Taking the average of the best 3 out of 5 runs for a couple of the junit
tests, I get the following:
TRUNK CMPLX DIFF%
well, the consensus seems to enable by default, which I have now done; to
disable, there are two methods:
(1) use '-nocs' option on command line
(2) use complex-scripts disabled=true/ in configuration file
this will go into my next patch to the Temp_ComplexScripts branch
On Tue, Jul 19, 2011 at
From the lazy user POV: Enable it by default, but if somebody compiles a list
of performance enhancement measures, be sure to remember this option.
Regards,
Georg Datterl
-- Kontakt --
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg:
13 matches
Mail list logo
