I will try building on my windows machine to see if I can track down the
problem. I think this might be a problem in the wingcc driver.
> On Jan 31, 2016, at 10:34 PM, Greg Jung <gvj...@gmail.com> wrote:
>
> Hi Alan,
>
> I don't program in plplot directly and so I'm pretty sure I'd be going
> through a month
> of debugging my own "example" before it would purport to show a plplot bug.
> I have put examples X02.cc and X20.cc together, removing the "delete
> plstream"s
> and found that X20's failure does not affect the X02 display. So I don't
> know how to target
> this symptom as it acts like a booby trap that gets tweaked by an innocent
> call.
> What I've done now is build GDL based on 5.11.1 with a statically linked
> plplot/qhull/shapelib
> so I don't reconfigure the effects away. This version has the mildest
> version of the "wrong" behavior
> so it looks like programming logic, better than the next worse behavior where
> all windows were
> blanked at once.
> I'll try to paste the screenshot in so it might get snuffed by the mailing
> list:
> <image.png>
>
> So, the two large wine-colored windows are the second phase of the test that
> are supposed to
> have Saturn images (shown in screenshot of earlier post). windows on the
> left were painted,
> with various color maps, from the same pyramidial distribution. They are
> created by plplot
> but the image is put on directly by the GDL driver (which is a plstream::
> class).
>
> The saturn images can be seen when the windows are being moved or resized.
> Also in the upper left window where I've overplotted with line drawings,
> when I resize those windows the painted image is seen while the mouse button
> is pressed.
>
> I can't capture this on screen because it reverts to the line drawing when I
> let go.
> o ok! now I see the reason for ::c_plclear() - I can erase the line drawing
> and the
> bitmap-drawn painted background stays on-screen. Because of my experiments
> with the
> GDL "erase" command which is
>
> $ grep -B2 clear /f/gdl/src/gdlwinstream.cpp
> plstream::scolbg(red0,green0,blue0); //overwrites col[0]
> ::c_plbop();
> // ::c_plclear();
>
> In this version I can erase the line-drawn but not the painted part. So I've
> done that on windows 5 and 12
> and re-positioned for a partial screen snapshot:
> <image.png>
>
> Now, this behavior is much healthier than the worst symptoms I've been having.
>
> That wine colored background is actually the color of background in the
> Linux/X11 test.
>
> Now I'll work on Phil's questions...
>
> On Sun, Jan 31, 2016 at 3:24 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca
> <mailto:ir...@beluga.phys.uvic.ca>> wrote:
> On 2016-01-30 20:22-0800 Greg Jung wrote:
>
> On Fri, Jan 29, 2016 at 12:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca
> <mailto:ir...@beluga.phys.uvic.ca>>
> wrote:
> So your best bet for getting help here is to show completely independent of
> GDL
> that there is actually an issue with the master tip version of PLplot
> that is unmodified by you other than possibly to modify one of our
> standard examples in order to demonstrate the problem.
>
>
> Ok I can simply build plplot without the bop() in rdbuf_bop and now I ask,
> which example does it affect in linux? linux runs x20.cc fine, but breaks
> in any case in windows 7. Example x02.cc, which is the only example using
> bop() explicitly, also
> works as it should without the plP_bop() call in rdbuf_bop.
> I don't have a prejudice, I don't know why the call messes my GDL windows
> up,
> but it does - and only in windows, not in xwin. Example x20.cc doesn't work
> on windows, but removing that call does not affect the example behavior.
> All I can
> do is report what I find, and there it is in terms of the examples.
>
>
> Hi Greg:
>
> Your justification for a change to PLplot might be entirely valid (I
> don't have the expertise to comment on that), but it is also not what
> I was hoping for from you. To clarify that, I would like a pure
> PLplot test case from you that demonstrates the same issue that you
> get with a combination of GDL and PLplot.
>
> In sum, what I am suggesting you do here is follow the usual first
> rule of debugging a complex issue, i.e., keep simplifying your test
> case until others can easily reproduce it. So the very first
> such simplification is to remove GDL completely from the mix while
> still demonstrating the same error. Can you do that first step for
> us by implementing a simple self-contained C, C++, or Python test case
> that generates exactly the same data and makes the same calls to
> PLplot functions in the exact same order that one of your GDL examples
> does that gives you bad plotting results?
>
> If that self-contained example does not demonstrate those bad plotting
> results that likely means (assuming the example uses the same data and
> PLplot calls) there is something wrong with the way that GDL
> interfaces with PLplot, and such an issue would be out of scope for
> us.
>
> On the other hand, if we obtain a self-contained pure PLplot test case
> from you that demonstrates the same problem as you get in the GDL +
> PLplot case then we are much further forward since there is a lot more
> we can do to verify and ultimately debug that self-contained test case.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca
> <http://astrowww.phys.uvic.ca/>).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net
> <http://freeeos.sf.net/>); the Time
> Ephemerides project (timeephem.sf.net <http://timeephem.sf.net/>); PLplot
> scientific plotting
> software package (plplot.sf.net <http://plplot.sf.net/>); the libLASi project
> (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links
> project (loll.sf.net <http://loll.sf.net/>);
> and the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net/>).
> __________________________
>
> Linux-powered Science
> __________________________
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
