On 2010-04-30 10:27+0200 Werner Smekal wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alan,
On 4/29/10 8:40 PM, Alan W. Irwin wrote:
On 2010-04-10 22:16-0700 Alan W. Irwin wrote:
Results from -dev xwin now look good, but the transformation from Hershey
index to unicode index is still a mess so results from modern devices
currently are also a mess. I hope to straighten that all out tomorrow.
This opened up a whole can of worms (one niggling detail after another), but
I finally got everything done as of revision 10952. This included
completely dropping the momentary switch to symbol fonts which we have
historically used in the PLplot core library to compensate for the
deficiencies (few glyphs per font) of Type 1 fonts. Instead, that switch to
symbol fonts is confined to the ps and pdf device drivers themselves where
it doesn't interfere with drivers (e.g., qt and cairo) which use TrueType
fonts.
Sorry, for dropping in late, but do you think that this is a good idea?
It's true that the hershey symbols look bad, but they are drawn fast.
And if you plot a lot of symbols (1000) the plotting gets annoyingly
slow, since so many text is drawn to the screen, while plotting the
hershey symbols is still blazingly fast even for a lot of symbols. So I
wouldn't get rid of this option, since it still makes sense to use
hershey symbols occasionally.
You should note that this interesting timing discussion (which I respond to
later in this post) is largely beside the point of my recent changes which
were almost entirely to do with improved handling of TrueType and Type1
fonts. I have just updated README.release to make that clear.
I also want to emphasize that the default behaviour with regard to Hershey
fonts remains unchanged. For example, we now have a -DHERSHEY_FALLBACK
option, but it defaults to ON (i.e., by default we get the prior behaviour
that if there is no unicode index corresponding to the Hershey glyph, then
we fall back to using the Hershey glyph as opposed to using a blank).
Similarly, certain device drivers (gcw, pdf, ps, psttf, and wxwidgets)
implement a hrshsym driver option to force Hershey glyphs for plpoin and
plsym (but not pl*tex) commands. That continues to default to ON (1) for
pdf and ps since the Type1 fonts (even the so-called Type1 Symbol font) are
missing so many important symbol glyphs that are accessible with the Hershey
fonts, but it continues to default to OFF (0) for gcw, psttf, and wxwidgets
because the TrueType fonts accessed by those devices have huge numbers of
symbol glyphs available.
The rest of this post is in response to the legitimate timing concern topic
you have brought up.
Before this I had never done any timing experiments myself comparing Hershey
and modern fonts, but it certainly makes sense to me that it would be faster
to use Hershey fonts than modern fonts since there are more file access
costs for modern fonts, and the data you have to process to generate a glyph
is more complicated for modern fonts. Here is one interesting timing
comparison with example 7 (which has thousands of calls to plsym).
softw...@raven time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=0
real0m0.995s
user0m0.224s
sys 0m0.044s
softw...@raven time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=0
real0m0.280s
user0m0.240s
sys 0m0.040s
softw...@raven time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=1
real0m0.111s
user0m0.092s
sys 0m0.024s
softw...@raven time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=1
real0m0.113s
user0m0.096s
sys 0m0.016s
I interpret the large timing difference between the first two hrshsym=0
results as due to the Linux kernel caching all the appropriate TrueType font
files into memory for quicker access the second time. The subsequent
hrshsym=1 results are consistent because the Hershey fonts had already been
read into memory by the first run of examples/c/x07c. So it is not a
completely fair comparison, but the ~ 3x faster access to Hershey glyphs
compared to TrueType glyphs once both sets of glyph data are cached in
memory does support the idea that Hershey access will always be faster than
access to modern fonts regardless of whether the required glyph data are
already cached in memory or not. Of course, for me the slower access is a
justified cost to pay for the much higher quality of the PLplot results for
modern fonts, However, that is a matter of opinion and obviously that
opinion depends on the speed of the computers accessible to the user. What
is a trivial cost for me may become an important cost for somebody using
PLplot on a low-power phone, for example.
Because some users will be legitimately concerned with timing costs, I think
we should have hrshsym capability for all our modern device drivers (e.g.,
cairo and qt). But it is already clumsy to have special driving options for
hrshym for so many different drivers so I would
