On 2017-10-04 12:11+0100 Phil Rosenberg wrote:
Note, I am including everything you wrote here (as opposed to dropping
parts of it) because the list has
not seen what you wrote because of the plplot-devel address that I flubbed.
I also respond in a few places below.
On 4 October 2017 at 05:54,
Phil, you should have seen the message below recently, but I am sending it again
because I flubbed the plplot-devel address for the first send.
On 2017-10-03 23:44+0100 Phil Rosenberg wrote:
On Windows the fill test took 5 seconds using the old comms method and
12 with the new. That's with opti
On 2017-10-03 12:34+0100 Phil Rosenberg wrote:
Can I also just check, in the end what was wrong with the previous
comms that I put in place? Didn't we eventually find that the source
of the delays was the random number generator for determining the name
of the shared memory and nothing to do wit
My best guess to this would be that every time new data is added to
the plot the wxPLViewer gets some new data and probably then calls
plreplot(). This then replots all the data from the beginning of the
stream including all the data that has previously been cleared and all
the clears. Whereas othe
On 2017-10-03 00:20+0100 p.d.rosenb...@gmail.com wrote:
Hi Alan
Are those timing values from the console side or the viewer side?
I failed to state how I measured time for the example 17 case but that
was done essentially identically to what I stated for the example 8
case, i.e., total time f
Hi Phil:
I just ran
examples/c/x17c -dev wxwidgets
for the HEAD of master (commit 124a0c3), and I very much like that
that commit implements "interactive" look
for the new wxwidgets device as illustrated by this example.
However, the rendering is slow (i.e., 2.5
minutes) compared to the similar
