TD Kanji PFR size/performance

Here is the first....
glen

-----Original Message-----
From: Bob Eggers [mailto:reggers@bitstream.com]
Sent: Wednesday, April 29, 1998 4:19 PM
To: Robert Eggers; Hiro Kataoka; Steve Lewis
Cc: Glen Rippel; John Collins
Subject: Re: Kanji PFR size/performance


Dear Hiro and Steve:

I reversed the PFR sizes of the compressed and non-compressed PFRs in this
email. To repeat, correctly now, the size of the Square Gothic Medium PFRs
is as follows:

Compressed Sqaure Gothic Medium:                2,001,330 bytes
Regular Square Gothic Medium:                       2,647,760 bytes

I have found the bug/problem on the OS9000 PPC build and have confirmed that
cps is equivalent to the PPC numbers on the Mac. This bug was on the
application/developer level, and not in the TrueDoc code.

Also, I will follow up with 68K metrics from a true 68K Macintosh. The
number I gave were on the PPC Mac running 68K code in emulation. Those
statistics are probably badly skewed lower due to the emulation mode.

Robert Eggers
OEM Project Leader
Bitstream, Inc.
617-520-8405

-----Original Message-----
From: Robert Eggers <reggers@bitstream.com>
To: Hiro Kataoka <hkataoka@bitstream.com>; Steve Lewis
<slewis@bitstream.com>
Cc: Glen Rippel <grippel@bitstream.com>; John Collins
<jcollins@bitstream.com>
Date: Wednesday, April 29, 1998 12:20 PM
Subject: Kanji PFR size/performance


>Dear Hiro and Steve,
>
>I had some problems getting performance figures from my OS9000 Powerstack
>(PPC 25 Mhz). There is an unresolved bug on that implementation for large
>character set fonts that impacts the cache performance. Since there is no
>profiling tool to analyse the source of the problem, it will take more than
>a few days to get to the bottom of it. There is also a problem with the
>Stellar 1000; there isn't enough RAM disk space to hold the Kanji font, so
I
>cannot test it.
>
>As a result, I ran the tests on a Power Mac 7100 running at 80 Mhz. Tests
>were done in both 68K and PPC builds.
>
>The font used for the tests was Square Gothic Medium, recorded from a full
>drawn TrueType (not stroke based). The number of characters in the font is
>7485. This is the full Unicode set encoded in the Microsoft character
>mapping table (also known as the 3:1 CMAP).
>
>Two versions of the PFR were recorded, both at 250 ORUs. One version is
>compressed, the other is not. The image quality of both fonts is excellent
>and indistinguishable from each other. The sizes of each are as follows:
>
>Compressed Square Gothic Medium:        2,647,760 bytes
>Regular Sqaure Gothic Medium:                2,001,330 bytes
>
>The cache size used was the CSPLIB default size of 64KB. This is much
larger
>than is needed for this test. The pixel depth used in TrueDoc is 4 bits per
>pixel. A depth of 8 bits could produce better performance, but is rarely
>used in the STB or embedded systems typically using 256 color CLUT (Color
>Look Up Table).
>
>The "Cache" test involves a paragraph with 118 characters. The paragraph is
>drawn once to populate the cache, then the timing test is performed by
>rendering the paragraph multiple times, counting characters. Timing
includes
>the BLT time, which in this case goes through the Mac CopyBits() function.
>Performance metrics were taken at heights of 7, 13 and 28 lines per em.
>
>The "No Cache" test involves a Waterfall of 18 characters, from 11 to 28
>lines per em. The sequence of generating the waterfall 10 times is timed,
>again including all BLT time on the Mac.
>
>These are the performance results observed:
>
>Compressed PFR:
>Processor                Cache                          No Cache
>68K                        1180 cps (7 lines)                34
>                              1180 cps (13 lines)
>                              1180 cps (29 lines)
>PPC                       2360 cps (7 lines)               278
>                              2360 cps (13 lines)
>                              1180 cps (29 lines)
>
>Regular PFR:
>Processor                Cache                          No Cache
>68K                        2360 cps (7 lines)                43
>                              1180 cps (13 lines)
>                               786 cps (29 lines)
>PPC                       2360 cps (7 lines)               340
>                              2360 cps (13 lines)
>                              1180 cps (29 lines)
>
>The timing anomalies apparent in this list are unexplained. Presumably the
>Mac OS occassionally intervenes in the background to "garbage collect".
>Cache performance in 68K and PPC is apparently equivalent. The PPC code is
>clearly faster when the characters are not in the cache and need to be
>generated from the outlines.
>
>Also quite clear is the same effect of the PPC processor is pronounced when
>handling compressed PFRs.
>
>It should be noted that the cps of Latin fonts in the PPC Mac build is
>within 100 cps of the performance of Latin fonts on the OS9000 Powerstack
>running at 25 Mhz. Presumably the BLT performance under OS9/MAUI is
>considerably faster than CopyBits on the Macintosh. I have found the Mac
PPC
>build to provide a very close metric to other PPC SetTop Boxes running at
25
>Mhz.
>
>Robert Eggers
>OEM Project Leader
>Bitstream, Inc.
>617-520-8405
>

Received on Monday, 8 June 1998 11:17:44 UTC