Hi Alan, I'll add a few comments here, and apologise to those who don't like top-posting but the comments are along various random directions. Many thanks for your remarks and explanations, which all make sense to me (at least to the extent that I need).
Firstly, I did set plsc->dev_hrshsym within my c-code, and the fact that commenting this line out made differences in my time trials shows that it did have some effect. I also deduced that some glyphs aren't available in unicode and were drawn from the hershey set anyway (hence the same times for using circles regardless of the value of dev_hrshsym). This whole matter came to my attention when I was plotting a large number of points - I wasn't surprised that it was slow although following my trials I was subsequently surprised that the qtwidget driver was so much slower than the xwin or tk, with xcairo usually somewhere in between. Of course, both the xcairo and qtwidget drivers do a better job in terms of quality, e.g., keeping circles circles, etc. What drove me, however, was that I then wanted to zoom into a region of my plot. To keep our code clean, we simply use plplot's clipping to do this kind of thing, so we pass all the points (which aren't necessarily in any order) and let plplot clip the plot. This also ensures we see the points at/very close to but off the boundaries. This appeared to me to be annoyingly slow, which started me down my investigations. Since yesterday, I have done some trials with such clipped values. Some drivers, like xwin and tk, are very quick in this case. And the qt and xcairo ones are similarly quick when a hershey glyph is used, but when a unicode one is they take the same amount of time to plot 10% of the data (with 90% clipped) as they do to plot all the data points. I haven't dug deep enough into the plplot code to see whether all this is down to the interaction with the screen pixels or whether some of the clipping is implemented within the drivers. Anyway, I wrote myself a small wrapper for plpoin that calls plgvpw and calls plpoin point by point but only for those points within the viewport (being careful that viewport axes are allowed to run backward :-)). Since plpoin calls plhrsh point by point this adds only a small overhead to the whole process (about 7% in my experiments) when all the points are plotted, but of course if 90% of the points are outside the viewport there is a substantial reduction in time. It also reduces the size of the qtpdf output files (but again only in the cases where a unicode glyph is used). I'll stop here. This is clearly an area that is frought with nuance and very hard to clean up given the variety of language bindings, operating systems, and drivers. Regards, Steve On Sat, 2010-06-05 at 23:39 +0100, Alan W. Irwin wrote: > Hi Steve: > > On 2010-06-05 20:01+0100 Steve Schwartz wrote: > > > Hi Werner, > > > > On Thu, 2010-06-03 at 20:12 +0100, Werner Smekal wrote: > >> For so much symbols I would suggest to use the hershey fonts for > >> symbols > >> with > >> > >> pls->dev_hrshsym = 1; > >> > >> text will be drawn still nicely. But I'm sure qtwidget should be as > >> fast > >> as xcairo or close to, so if the 7.5 second are ok for you, I would > >> definitely look how text plotting is managed in xcairo and in > >> qtwidget. > > > > Thanks for this; it sounded like a sensible idea, but after extensive > > trials, the result is mixed. I attach for your amusement the result of a > > variety of trials for various different interactive devices (xwin, tk, > > xcairo, and qtwidget), plotting various symbols (plus sign, circle, > > filled dot) in various sizes (plssym(0.0, scale)), and with > > plsc->dev_hrshsym set to 0 (unicode) or 1 (use hershey). I also attach > > the code I was playing with to do this, which is a hacked and > > stripped-down version of x01c. It was compiled using the Makefile in my > > examples/c folder. > > > > Here are some brief conclusions: > > > > For some plot symbols xcairo is faster (by almost a factor of 10) when > > using hershey font for them rather than unicode. I guess this is > > Werner's experience. > > > > However, the qtwidget is actually slower when the hershey fonts are > > invoked (about 50% more time). See the entries with green and blue > > backgrounds in the attached spreadsheet. The simple filled dot takes 6 > > times as long with a hershey font. > > > > Simple circles are an exception to the above and take the same time > > regardless of whether the hershey or unicode fonts are used, and this is > > true for all the drivers. > > Some circles do not currently have a unicode equivalent. Try > the -DHERSHEY_FALLBACK=OFF option (see explanation below) to be more > sure of what you are getting. > > > > > Generally, the qtwidget driver is significantly slower than the others, > > and I guess the attached results suggest that this is internal to qt. > > > > I also tried plotting to pdf files using cairo and qt. I expected to see > > the unicode font containing the symbol in the pdf "properties" list of > > fonts, but it isn't. [I removed all the plot labelling which resulted in > > a pdf with no fonts required/embeded.] > > This might not be true any longer, but early versions of the Adobe > PostScript and PDF standards only officially recognized Type 1 embedded > fonts. So for the psttf device, TrueType fonts are implemented by embedding > drawing commands for each glyph directly into the PostScript file that is > produced by that device. This doesn't violate the Adobe standard, but I > doubt those grouped embedded drawing commands would ever be recognized as > official embedded fonts by the Adobe standard. I assume the same is true of > PostScript and PDF results produced by the epsqt, pdfqt, pscairo, and > pdfcairo devices. > > As a general comment, the response you get for font tests depends very much > on the symbol you pick, what device you are using, and what CMake and > run-time options you are using. Both plpoin and plsym are legacy API that > were originally designed to access Hershey fonts in various ways. For > example, if you pick an "ascii" code number for plpoin, that gets translated > internally into a symbol number for Hershey fonts. You can also access that > symbol number directly using plsym. For devices that are not unicode aware > (such as xwin) the Hershey glyph is found corresponding to that Hershey > symbol number and drawn directly by the core PLplot library. > > For unicode-aware devices (e.g., qtwidget, xcairo) the situation is more > complicated. We maintain a table to translate between Hershey symbol number > and unicode (UCS4) index value (see fonts/plhershey-unicode.csv), but some > Hershey symbols just do not have a Unicode equivalent. If the user sets > -DHERSHEY_FALLBACK=OFF (which I recommend for font testing since it does not > obfuscate the results so much), Hershey symbols without a unicode equivalent > are translated to Unicode blank. However, for your tests you probably used > the default -DHERSHEY_FALLBACK=ON which means the Hershey glyph will be used > in these situations. That default is the best for ordinary use, but it does > tend to confuse test interpretation. > > I think these further two considerations did not affect your tests, but I > will mention them anyway for someone who is reading this thread later. > > plsc->dev_hrshsym is only set by certain devices. For example, there is no > driver option to control that value for either qt or cairo devices. So to > be sure to force Hershey in such testing for unicode-aware devices you > should set that in your C test code rather than relying on driver options. > > plsc->dev_hrshsym only affects the plhrsh routine which in turn is called > only by plpoin, plpoin3, and plsym, but which is _not_ called by plmtex, > plmtex3, plptex, and plptex3. > > In sum, we have a complex decision tree about whether a Hershey glyph or > unicode glyph is chosen for plpoin, plpoin3, and plsym. In contrast, plmtex, > plptex, and their 3D counterparts always use Hershey glyphs if the device is > not unicode-aware, and otherwise use modern fonts for unicode-aware devices. > > I hope this explanation of our glyph choosing logic helps you refine the > interpretation of your tests. > > 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 > __________________________ -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.schwa...@imperial.ac.uk Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
