On 2009-04-24 09:35+0200 Werner Smekal wrote:
> Hi Alan,
>> My tests indicate the normal qt devices and this important additional
>> ability to access the PLPlot API from Qt applications are now in good shape
>> for our early May release. However, it's a good idea to broaden the tests
>> to additional platforms and configurations so I ask the developers/testers
>> here to do your own thorough testing of these qt and Qt capabilities
>> now and the release on all accessible platforms, and, of course, report
>> any bugs you might find.
> Mac OS X
> * I installed the latest Qt SDK 4.5.1 and added the instructions to the wiki
> * Everything compiles without troubles.
> * If I run an example (qtwidget) with one plot a window pops up which remains
> black. The only way to proceed is the right mouse button. Windows closes.
> * If I run an example (qtwidget) with more than one plot (x08) than window
> pops up which is black. Proceeding with the right mouse button shows then the
> following plots correctly. Plotting speed is slow but acceptable.
> * I run ctest --verbose and it passed all tests regarding the qt device.
> * Still use the "old" QT SDK 4.5.0 for MinGW only.
> * Everything compiles.
> * Examples run correctly, only right mouse button proceeds. But plots are
> extremely slow. In example 8 one plot needs more than 4 seconds to show up
> (Pentium M 1.6Ghz, 4.5 year old laptop). Wingcc needs fraction of a second.
> wxWidgets less a second.
> * ctest run out of disk space ;)
You know this already, but just to remind everybody else here, Trolltech
just released Qt-4.5.1 (a bug fix release for Qt-4.5.0) which is
downloadable from http://www.qtsoftware.com/downloads.
I have repeated some of the detailed tests I did with Qt-4.5.0 for Qt-4.5.1,
and there doesn't seem to be any noticeable difference.
Thank you for these qt tests. However, I would suggest following up
on both Mac OS X and MinGW by viewing at least some of the file results that
have been generated. Of course, there are so many file results to look at so
it is essential to automate the viewing process. For my testing, I do that
using the bash shell for loop, e.g.,
for EPS in x*.epsqt; do echo $EPS; gv $EPS; done
You have access to shell facilities both on Mac OS X and MinGW so automating
the viewing process like this should be straightforward on both platforms.
Note, there are five different software families of devices for the qt
device driver. These are the raster devices (e.g., pngqt, jpgqt, etc.,),
the "Adobe" devices (epsqt and pdfqt), the SVG device (svgqt), the
interactive device (qtwidget), and the external device (extqt).
All devices within a qt software family are treated essentially identically
(except only for the specification of the format to be used). Thus, spot
checks that each member of a family is viewable are worthwhile, but detailed
viewing of all examples in a family can probably be confined to just one qt
device per qt software family.
Note that as of revision 9846, "make test_interactive" in the installed
examples tree exercises qtwidget for an important subset of the examples and
also runs examples/c++/qt_example (which constitutes our only test of the
extqt device). So that takes care of testing for those two families. For
my own detailed viewing of file results, I chose to look at all example
pages for only epsqt, pngqt, and svgqt.
For the platform where you are short of disk space, I suggest you exclude
all devices other than the qt ones you are testing. That should save
you something like 2GB of file results from ctest (or make test in the
installed examples tree).
One question to be answered by the suggested detailed viewing is whether the
black first page problem you identified for Mac OS X shows up for all qt
devices or just qtwidget. Of course, the detailed viewing also helps to
find any software issues exclusive to a particular qt software family.
Your comments on speed of qtwidget versus wingcc inspired me to do some
speed tests comparing -dev png -dev pngqt, and -dev pngcairo results. There
are some similarities between -dev wingcc and -dev png since the wingcc and
gd device drivers were both written by Andrew Roach and both use the
plfreetype approach to render unicode fonts. But actually these speed test
stands on their own for a comparison of speeds between and old-fashioned
rendering library (gd) with a number of issues, and modern rendering
libraries such as libpango/libcairo and the Qt4 suite of libraries.
Here are the results:
software@...> time ./plplot-test.sh --front-end=c --device=png
Testing front-end c
Output file name is ./x31c01.png
software@...> time ./plplot-test.sh --front-end=c --device=pngqt
Testing front-end c
Output file name is ./x31c01.pngqt
software@...> time ./plplot-test.sh --front-end=c --device=pngcairo
Testing front-end c
(process:31920): Pango-WARNING **: Error loading GPOS table 5503
(process:31964): Pango-WARNING **: Error loading GPOS table 5503
Output file name is ./x31c01.pngcairo
-dev png and -dev pngcairo are pretty similar in speed, but -dev pngqt has
significantly better speed than the rest.
I also tried example 8 with qtwidget versus wxwidgets (AGG) versus xwin
hammering the right click (qtwidget) or return (wxwidgets and xwin) as
quickly as possible to get through the test as quickly as possible. Here
are the results:
software@...> time c/x08c -dev qtwidget
software@...> time c/x08c -dev wxwidgets
software@...> time c/x08c -dev xwin
The elapsed time was better for qtwidget than for wxwidgets (AGG) and always
reproducible. However, xwin was much faster than either. Of course no
interactive device beats xwin for speed on Linux, but you pay for it in
terms of lousy text quality (only Hershey fonts available).
>From these good qt speed results, I am a bit surprised you are getting such
slow speed with the interactive qt device compared to other interactive
devices on MinGW. Are you making a fair comparison with regard to text
quality? What is the underlying Windows platform there? I wonder
if Qt-4.5.0 is just not very well optimized for whatever display canvas
(presumably not X) that it is using for that particular Windows platform.
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