Re: [Plplot-devel] Slow symbol rendering on some devices

[Alan W. I. <ir...@be...>]

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
__________________________