Hi Alan
Sorry I only just spotted your email.
I have just made a commit, but it was technically a bug fix (or at
least half of it was), but I won't make any further commits.
Phil
On 11 March 2015 at 10:49, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 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
