I can now put my hands up and say the regression was me. At least on
my Centos machine running the xwin driver results in a blank window
and a hang until I checkout before this commit
commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
Author: Phil Rosenberg <p.d.rosenb...@gmail.com>
Date: Fri Feb 27 17:12:03 2015 +0000
Fixed bug in rdbuf_di.
Save cursubpage on replot
call plP_eop() on replot which ensures that the first plP_bop() call
actually does something.
I guess that somehow I have set up an infinite loop of eop/bop calls
or something.
If someone would like to confirm that this is the faulty commit then
please let me know. The commit before this is
1e3786c758f78bff13086cf26ab81145b4e2e14d which works for me.
I will try to find some time to work on this tonight or tomorrow night.
Phil
On 11 March 2015 at 13:01, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
>>
>> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
>> of the pie chart, but the other slices are fine.
> This isn't shown on Windows. Perhaps the cause is that both the lines
> and the fill are being saved to the buffer meaning the lines get
> rendered twice. This is just a guess though
>>
>> * Example 17 is extremely slow to display and the erases are not getting
>> done when the plot is rescaled. Attached mode?
>
> I will add this to my to do list
>
>>
>> * 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).
>
> Again I will add it to my list
>
>>
>> * Example 26.02 still has an issue with too large a legend for
>> the Cyrillic version of the plot.
> See my post to a different thread.
>>
>> * 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."
>> ^^^^^^^^ ^^^^^^^
>
> I don't see this on Windows wx3.0, Ubuntu wx3.0 or Centos wx3.0 so
> you'll have to send me a screen shot.
>
>>
>> 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.
>
> Already known, but better than it was
>
>>
>> * 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).
>
> Same as the old driver - I will add native gradient fill to my to do
> list, but I would guess that shading with alpha is broken in general.
> This is due to outlining as a workaround to the seaming problem for
> solid colour shading. It will need some changes to the core code to
> fix.
>
>>
>> * 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).
>
> Again I'll add it to the list
>
>>
>> * To get proper interactive capability, must implement an
>> attached driver option that does not launch a separate
>> wxPLViewer instance.
>
> This will not happen (well at least not from me). The whole point of
> the changes was to detach the driver, because wxWidgets is not
> designed to be attached.
>
>>
>> * 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).
>
> This is a bug, it was supposed to be pls->dev = NULL. This has
> potential to cause segfaults as it leaves a dangling pointer if
> initialisation fails. However I will leave this unless you say you are
> happy for me to apply the appropriate fix.
>
>
> Also you will have to let me know if you are still happy for me to
> change the documentation.
>
> Phil
------------------------------------------------------------------------------
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
