On 2015-03-10 21:41-0000 Phil Rosenberg wrote:
> Hi Alan and Jim
> Right, well Jim's patch series is committed and I have just made one
> more additional commit regarding the buffer which I think now gives us
> a buffer which is (pretty close to, if not completely) bug free!!! Or
> at the very least it is sufficient to allow the wxWidgets driver to
> render as well as from direct commands.
Note, to everybody. There is an official deep freeze notice near
the end of this e-mail.
@ Andrew, Phil, and Jim:
Before getting to wxwidgets test results I regret to say that a recent
plbuf change has nailed us again. There is now a release showstopper
where -dev tk produces really strange looking results. I found this
issue via checking -dev tk for the zoom regression where hitting the
zoom button just produces a blank (black) plot. I confirm that
regression as well as a newly introduced regression for that device
(two windows are displayed rather than one with one of them without a
plot but with the plframe decorations and the other showing an
xwin-like plot windows with no decorations). This new regression and
the zoom regression are showstoppers for the current release so your
confirmation and fix for these rendering regressions will be much
appreciated. You should also look carefully at -dev wingcc to see
whether recent plbuf changes have introduced rendering regressions
there as well (assuming you have looked in detail before at wingcc
results for all examples, and therefore know what rendered nicely in
the old days).
If none of you beat me to it, I will follow up starting roughly 12 hours
from now with a git bisect to find out the first commit that caused
each of these regressions, and hopefully the fix for each regression
will be straightforward after that.
@Arjen:
Just in case you remember how well wingcc rendered before, I would
appreciate you double-checking how wingcc renders now.
@Phil:
Naturely, I found the above new rendering regression right at the end
of a very long series of tests of wxwidgets which I will probably have
to repeat once the above plbuf issue(s) are fixed (sigh). So for what
it is worth, here is the current status of wxwidgets on Linux as of
commit id = afd37a9.
I did this long test with the following command:
for SEQ in $(seq -w 0 33); do
examples/c/x${SEQ}c -dev wxwidgets
read ANSWER
done
(where "read ANSWER" supplies a pause between examples
so you don't have one zillion instances of wxPLViewer going
at the same time).
There is a definite improvement compared to when I ran such a test
before, but I note the following large number of minor issues (mostly
rendering issues and non of them are release critical) that still
exist on Linux:
* text much too small for all examples. Increasing
all text sizes by something close to a factor of two (say
to fill all the squares by the numbers in example 2.2 just like
for the xcairo, qtwidget, and xwin device) is needed.
* Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
of the pie chart, but the other slices are fine.
* Example 17 is extremely slow to display and the erases are not getting
done when the plot is rescaled. Attached mode?
* Example 20 is extremely slow to display and does not have any
interactive capability (the third page should allow you to select a
region with the cursor). Compare the cursor capability shown with
this example for -dev xwin.
Note -dev wxwidgets cursor capability is currently similar to
that of -dev xcairo and -dev qtwidget. All three devices print
out cursor position results for example 1 with the -locate option,
but all three devices fail to allow the user to select
a region in example 3.03. So all three have to be updated
to have the same cursor capabilities as -dev xwin.
In addition, I presume this capability would only work
for the qtwidgets case in attached mode (see below).
* Example 26.02 still has an issue with too large a legend for
the Cyrillic version of the plot.
* Example 28.04 has a strange colour change for certain ranges indicated
below of the rendering of the
"The future of our civilization depends on software freedom."
^^^^^^^^ ^^^^^^^
3D string. Those colour changes occur when the letters in the string
are mostly reduced to the (expected) straight lines by the 3D affine
transformation. This may be due to some strange issue with my Debian
stable wxwidgets software library and have nothing to do with PLplot.
If you cannot reproduce those colour changes, I will send a screen
shot.
* Example 28.05 affine transformation issues.
* Example 30.02 ugly looking gradient results are due to falling back
to core software emulation of a linear gradient. Instead, as
discussed before a linear gradient based on the wxwidgets API should
be used instead to get very nice results for this example (such as
those from the cairo and qt devices).
* Example 34: the qtwidgets device does not support draw mode.
However, if you want to implement this someday you should follow what
is done for xcairo (which is the only device so far that has draw mode
capability).
* To get proper interactive capability, must implement an
attached driver option that does not launch a separate
wxPLViewer instance.
* There was also a the following warning being emitted by g++
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In
function ‘void plD_init_wxwidgets(PLStream*)’:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:186:23:
warning: converting to non-pointer type ‘PLINT {aka int}’ from NULL
[-Wconversion-null]
Did you really want to set the device id (which is just an integer) to
zero here? If so, you should use 0 rather than NULL. But I thought
that device id integer was supposed to be fixed and unique to each
device in which case it would generally not be a good idea to zero it. But on
the other hand, I so far have not detected any issues from this
zeroing so I don't think there is any urgency here
(i.e., you can deal with this post-release).
> [....] I guess that [good results for wxwidgets] means you can freeze the
> core code Alan. I'm
> going to just make a couple of wxWidgets mods this evening and then I
> am going to stop meddling until after the release. I do still need to
> sort the docs out as well.
>
I think it is definitely time to be extremely conservative about all
commits to master because we just experienced a counter-example where
plbuf changes were committed without sufficient testing (in retrospect
something that is all-too-easy to do since plbuf has such a wide
impact). So I highly recommend dealing with all the above wxwidgets
issues on a topic branch and waiting until after the release to merge
those fixes to master while we focus on the master branch with dealing
with the regressions introduced by the plbuf changes. Also, note I
would be happy to make the next release cycle much shorter, i.e., have
another release just as soon as you finish the above list and want to
get those fixes quickly distributed to users.
@Everybody:
To make this decision official, this is notice from your release manager
that we are now in deep freeze until release. That is, only
documentation changes and small and _very well tested_ fixes should be
pushed to master during this deep freeze. In particular, because
plbuf changes have such a wide impact, I ask everyone here to avoid
commits to master that involve any plbuf changes at all during deep
freeze unless such commit can be shown to fix a non-wxwidgets
rendering regression caused by an earlier plbuf change in this release
cycle.
Also, despite the extra effort we are going to need to deal with the
rendering regressions, I do honestly want to thank both Phil and Jim
for all their hard work on wxwidgets/plbuf that has finally gotten us
to the point where we can declare a deep freeze. That's a really
important goal for late in a release cycle, and I am really glad we
have finally achieved that goal!
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
__________________________
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
