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 real 0m0.995s user 0m0.224s sys 0m0.044s softw...@raven> time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=0 real 0m0.280s user 0m0.240s sys 0m0.040s softw...@raven> time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=1 real 0m0.111s user 0m0.092s sys 0m0.024s softw...@raven> time examples/c/x07c -dev psttfc -o test.ps -drvopt hrshsym=1 real 0m0.113s user 0m0.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 suggest the best thing would be to have a hrshsym core option which defaults to off (0). That would allow removal of the driver option for gcw, pdf, and wxwidgets (and potentially for cairo and qt and other devices). ps and pdf would have to be special cases with a default of on for obvious reasons. Werner, if you agree a central hrshsym option that defaults to off is worthwhile (with a driver option override for just ps and pdf), will you take responsibility for that implementation the next time you have an opportunity to work on PLplot? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
