Re: [Plplot-devel] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

On 2016-01-06 16:35-0000 Phil Rosenberg wrote:

> You should now have a working version on Linux. It certainly seems to
> work on my CentOS machine.

Yep. Works fine here with no build or run-time problems other than the
idle issue(s) which I document below for this (commit 4677df1) version
of wxwidgets.

Here are the additional local changes I made to make example 00 pure
line graphics with no text, example 23 pure ascii text with no
graphics, and a given example (in this case example 00, but I
modified it to example 23 for the example 23 tests) is repeated 19
times (10 times for the example 23 case) when building the
test_c_<interactive device> target.

==================
diff --git a/examples/c/x00c.c b/examples/c/x00c.c
index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
      plinit();

      // Create a labelled box to hold the plot.
-    plenv( xmin, xmax, ymin, ymax, 0, 0 );
-    pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+    plenv( xmin, xmax, ymin, ymax, 0, -2 );
+    //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );

      // Plot the data that was prepared above.
      plline( NSIZE, x, y );
diff --git a/examples/c/x23c.c b/examples/c/x23c.c
index 5dddf3b..3b67a60 100644
--- a/examples/c/x23c.c
+++ b/examples/c/x23c.c
@@ -229,6 +229,7 @@ main( int argc, const char *argv[] )

      plinit();

+#if 0
      for ( page = 0; page < 11; page++ )
      {
          pladv( 0 );
@@ -292,6 +293,7 @@ main( int argc, const char *argv[] )
      printf( "For example 23 prior to page 12 the FCI is 0x%x\n", fci_old );
      printf( "For example 23 prior to page 12 the font family, style and weight are %s %s %s\n", family[ifamily], style[istyle], weight[iweight] );

+#endif
      for ( page = 11; page < 16; page++ )
      {
          PLFLT dy = 0.030;
diff --git a/plplot_test/test_c_interactive.sh.in b/plplot_test/test_c_interactive.sh.in
index 6e6ceea..3736a0a 100755
--- a/plplot_test/test_c_interactive.sh.in
+++ b/plplot_test/test_c_interactive.sh.in
@@ -27,12 +27,12 @@
  lang="c"
  export index lang

-if [ "$device" = "xcairo" -o "$device" = "qtwidget" ] ; then
+if [ "$device" = "xcairo1" -o "$device" = "qtwidget1" ] ; then
      # Temporarily drop example 17 for xcairo and qtwidget because those drivers are
      # so horribly slow for such interactive plots.
      INDEX="01 04 08 14 16 24 30"
  else
-    INDEX="01 04 08 14 16 17 24 30"
+    INDEX="00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "
  fi
  for index in $INDEX; do
      if [ "$verbose_test" ] ; then
==================

Please look at the attached screenshots of results from my system
monitor.  The only relevant part to look at is the cpu history, and
all these results were obtained by running X on the same computer
where the desktop software was running.

I. Pure line graphics results from 19 repetitions of modified example 00.

Ia. Comments on screenshot_others00.png

The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget.  Each of
these targets completes the 19 runs of modified example 00 in
respectively 2.5, 2.9, and 4.0 seconds.  These numbers are confirmed
by the relative width of each of the major 3 peaks.

Ib. Comments on screenshot_wxwidgets00.png

This is my primary evidence of the idle problem(s) for a pure line
graphics case (modified 00 example).

This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).

The initial large peak corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built.  That peak is then followed by 11 more peaks as -dev
wxwidgets runs through 11 of the 19 example 00 repetitions before I
had to take the screenshot so as not to miss the first peak.  You can
see for each of these examples both my cpus are engaged, and a given
repetition consists of mostly idle time of wildly different durations
with one modest peak of cpu(s) activity per repetition.  It turns out
these modest peaks correspond to exactly when the wxPLViewer GUI is
visible on the screen (although it just displays a black screen during
that time because of the -np issue with wxPLViewer). From the random
duration of the idle times for each repetition the figure for the
total time that all 19 repetitions take is quite variable. However,
the one time I had the patience to measure the time required for the
full 19 the result was 467 (!) seconds which is more than two orders
of magnitude larger than corresponding example 00 results for three
other interactive devices that I give above.

II. Pure ascii text results from 10 repetitions of modified example 23.

IIa. Comments on screenshot_others23.png

The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget.  Each of
these targets completes 10 runs of modified example 23 in
respectively 3.3, 4.3, and 5.4 seconds.  These numbers are confirmed
by the relative width of each of the major 3 peaks.

Comments on screenshot_wxwidgets23.png

This is my primary evidence of the idle problem(s) for a pure ascii text
case (modified 23 example).

This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).

The initial large peak (all of which is clipped off on the left except
for the trailing part) corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built.  That peak is then followed by 8 more peaks as -dev
wxwidgets runs through 8 of the 10 example 23 repetitions before I had
to take the screenshot so as not to miss all of the first peak.  The
remarks I made concerning variability of idle time, coincidence of the
peaks with GUI display for screenshot_wxwidgets00.png all apply for
this case as well. The one time I measured the time required for the
full 10 repetitions the result was 113 seconds or more than an order
of magnitude more than the corresponding example 23 results for three
other interactive devices that I give above, but almost an order of
magnitude less than the modified example 00 case for wxwidgets.

In sum, it appears that we may have at least two separate idle issues
left on Linux for -dev wxwidgets since the time required to get
through the repeated modified x00 example is roughly equivalent to the
corresponding time taken for the repeated x23 example for the other
interactive devices, but almost an order of magnitude slower for
repeated x00 versus repeated x23 for the wxwidgets device.

So the biq question is can you replicate these results (at least the
one or two order of magnitude differences in relative total times
involved to run these various targets) on your own two Linux systems
or are they idiosyncratic to my Debian jessie platform?

Assuming you can replicate, then good luck on the bug hunt to find
the source of these Linux idle issues.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________