plplot-devel

[Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

Hi all,

   I've been having difficulties under windows with plplot 5.11+
when used with GDL (gnudatalanguage).  When I run a test
that exercises 2-d bitmaps and line plots together (test_tv.pro),
 I got wrong behavior.  I discovered the offense did not happen
for plplot created in December 2014  - which I had saved - but
every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.

 I narrowed it down to the single line call to plP_bop() at the end
of the rdbuf_bop routine.  When this call is not made from plbuf.c,
everything is working well (using wingc).

Within the GDL usage constraints, this call does not seem needed
when used for xwin.c, either.
  Another issue possibly related, from GDL the gdlstream::Clear()
call which was also responsible for bad behavior:

/f/gdl/src/gdlwinstream.cpp-      plstream::scolbg(red0,green0,blue0);
>
> /f/gdl/src/gdlwinstream.cpp-    ::c_plbop();
>
> /f/gdl/src/gdlwinstream.cpp: //     ::c_plclear();
>
>
c_plcear() was another thing messing up the GDL plotting.  Again,
if I also removed ::c_plclear for the xwin driver, this was no detrimental
effects.

I suspect that if plP_bop() should be generally called from plbuf then
whatever is going wrong should be fixed in wingcc.

Greg

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

On 2016-01-28 17:15-0800 Greg Jung wrote:

> Hi all,
>
>   I've been having difficulties under windows with plplot 5.11+
> when used with GDL (gnudatalanguage).  When I run a test
> that exercises 2-d bitmaps and line plots together (test_tv.pro),
> I got wrong behavior.  I discovered the offense did not happen
> for plplot created in December 2014  - which I had saved - but
> every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.

Hi Greg:

Please use the "git bisect" command to find the actual commit where
this bad behaviour starting occurring.  That will provide some useful
overall context to the other things you discovered below.

Alan

>
> I narrowed it down to the single line call to plP_bop() at the end
> of the rdbuf_bop routine.  When this call is not made from plbuf.c,
> everything is working well (using wingc).
>
> Within the GDL usage constraints, this call does not seem needed
> when used for xwin.c, either.
>  Another issue possibly related, from GDL the gdlstream::Clear()
> call which was also responsible for bad behavior:
>
> /f/gdl/src/gdlwinstream.cpp-      plstream::scolbg(red0,green0,blue0);
>>
>> /f/gdl/src/gdlwinstream.cpp-    ::c_plbop();
>>
>> /f/gdl/src/gdlwinstream.cpp: //     ::c_plclear();
>>
>>
> c_plcear() was another thing messing up the GDL plotting.  Again,
> if I also removed ::c_plclear for the xwin driver, this was no detrimental
> effects.
>
> I suspect that if plP_bop() should be generally called from plbuf then
> whatever is going wrong should be fixed in wingcc.

__________________________
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
__________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Jim D. <ji...@di...>]

> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
> 
> Hi all,
> 
>    I've been having difficulties under windows with plplot 5.11+
> when used with GDL (gnudatalanguage).  When I run a test
> that exercises 2-d bitmaps and line plots together (test_tv.pro <http://test_tv.pro/>),
>  I got wrong behavior.  I discovered the offense did not happen
> for plplot created in December 2014  - which I had saved - but 
> every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.
> 

Can you describe the wrong behavior?  Does it occur when you resize?

>  I narrowed it down to the single line call to plP_bop() at the end
> of the rdbuf_bop routine.  When this call is not made from plbuf.c, 
> everything is working well (using wingc).
> 

I will take a look at the plP_bop() call in rdbuf_bop().  My suspicion is that it shouldn’t be removed.

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:

>
> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>
>
>
> Can you describe the wrong behavior?  Does it occur when you resize?
>
There's no re-sizing involved.   The image is put up via
SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
                            0, 0, rt.bottom + 1, tv_buf.lpbitmap, &tv_buf.bi,
DIB_RGB_COLORS);
 found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage


 The test involved
part 1: multiple windows, where a simple distribution  is laid out.  colors
are reloaded
(scmap0) and the distribution is painted.

a=DIST(xdim, ydim)
b1=REFORM(a,1, xdim, ydim)
b2=REFORM(a,xdim, 1, ydim)
b3=REFORM(a,xdim, ydim, 1)
;
icolor=0
MY_WINDOW, 0, a
loadct,icolor & icolor++

MY_WINDOW, 1, b1
loadct,icolor & icolor++
MY_WINDOW, 2, REFORM(b1)
loadct,icolor & icolor++
MY_WINDOW, 3, b2
loadct,icolor & icolor++
MY_WINDOW, 4, REFORM(b2)
loadct,icolor & icolor++
MY_WINDOW, 5, b3
loadct,icolor & icolor++
MY_WINDOW, 6, REFORM(b3)
loadct,icolor & icolor++

where MY_WINDOW =
   1. create window of size to hold the 2-d
   2. Put up the 2-D onto window
For each window a different color table was loaded (icolor++)
[image: Inline image 2]
  Then this distribution is applied to sections of a larger window.
  This works except  on the last test where a different color table should
show for each sub-section.
[image: Inline image 3]
then a few exercises of "TV" routine are made, which puts the saturn.jpg
image on a window where line-plots are already made:
[image: Inline image 4]
The actual wrong behavior; it ranged from segfaults to all of the windows
blanking, to everything showing but the saturn image.
 To find when it occurs, I built using historical plplots until I found it
was between Jan 15 and Feb 1.  The changes in plbuf were too coarse to use
plgit at that stage so I advanced plbuf from the working version towards
the final plbuf.c:

greg@Homerw7 MINGW32 /d/dated/plplot-git/plplot-150115
$ git log
commit cd749d09d1f6cbad3172e1b0b04910fc8ae3f4d8
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 08:15:19 2016 -0800

       more plbuf.c advances.  seqfaults when attempting to implement
rd_data_no_copy etc.

commit b4411c72cd6c75c506574699adbb6cbfe9a7f8d2
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 06:57:54 2016 -0800

      see patches/0000-656am.patch.  Compiles and runs gdl test_tv

commit 27096a39cfac94c988b069d3ea94dd4c11fb3848
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 06:22:52 2016 -0800

      This commit brings 150115 to the edge of break, in caase of plsdef.c,
where
      invoking  plP_state( PLSTATE_CHR ); at line 208 or
    possibly line 255 produces a segfault in win32 builds.

commit ccfee95ac0370f00f97b0e0deeebc450545b47e1
Author: Alan W. Irwin <ai...@us...>
Date:   Thu Jan 15 13:22:42 2015 -0800

    Build System: Fix bug for case where no display

A successful test would have the above pics displayed on the terminal
[image: Inline image 5]

 The patch files below document the changes made from the base  ccfee95ac03
git.  Using Winmerge, I compared src/ with later versions to test when a
problem cropped up.

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Phil R. <p.d...@gm...>]

I seem to remember we added those calls in because they are needed to wipe
the memory left over at the end of a plot. For example if a user starts
plotting with the default colours or colours left over from the previous
page then changes them half way through, when the plot is resized and if we
didn't have some sort of bop event then the plot would get redrawn with the
incorrect new set of colours. Same occurs for line width and other state
variables.

But in addition, there needs to be a way to set the current subpage, and
the subpage size. Otherwise when the clear command comes later the driver
does not know how big an area to clear. I think the bop call also does
things like reset the scale so that text is the right size - again
remembering that we should be able to just play a buffer on an empty
driver, which would otherwise have no idea of these variables.

The clear is definitely required, because the clear applies to each
subpage, not to the whole page and I think the user can set each subpage to
a different clear colour. So we need to time the clears correctly when we
are clipping to the correct subpage.

Phil


On 29 January 2016 at 08:13, Greg Jung <gv...@gm...> wrote:

>
>
> On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:
>
>>
>> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>>
>>
>>
>> Can you describe the wrong behavior?  Does it occur when you resize?
>>
> There's no re-sizing involved.   The image is put up via
> SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
>                             0, 0, rt.bottom + 1, tv_buf.lpbitmap, &
> tv_buf.bi, DIB_RGB_COLORS);
>  found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage
>
>
>  The test involved
> part 1: multiple windows, where a simple distribution  is laid out.
>  colors are reloaded
> (scmap0) and the distribution is painted.
>
> a=DIST(xdim, ydim)
> b1=REFORM(a,1, xdim, ydim)
> b2=REFORM(a,xdim, 1, ydim)
> b3=REFORM(a,xdim, ydim, 1)
> ;
> icolor=0
> MY_WINDOW, 0, a
> loadct,icolor & icolor++
>
> MY_WINDOW, 1, b1
> loadct,icolor & icolor++
> MY_WINDOW, 2, REFORM(b1)
> loadct,icolor & icolor++
> MY_WINDOW, 3, b2
> loadct,icolor & icolor++
> MY_WINDOW, 4, REFORM(b2)
> loadct,icolor & icolor++
> MY_WINDOW, 5, b3
> loadct,icolor & icolor++
> MY_WINDOW, 6, REFORM(b3)
> loadct,icolor & icolor++
>
> where MY_WINDOW =
>    1. create window of size to hold the 2-d
>    2. Put up the 2-D onto window
> For each window a different color table was loaded (icolor++)
> [image: Inline image 2]
>   Then this distribution is applied to sections of a larger window.
>   This works except  on the last test where a different color table should
> show for each sub-section.
> [image: Inline image 3]
> then a few exercises of "TV" routine are made, which puts the saturn.jpg
> image on a window where line-plots are already made:
> [image: Inline image 4]
> The actual wrong behavior; it ranged from segfaults to all of the windows
> blanking, to everything showing but the saturn image.
>  To find when it occurs, I built using historical plplots until I found it
> was between Jan 15 and Feb 1.  The changes in plbuf were too coarse to use
> plgit at that stage so I advanced plbuf from the working version towards
> the final plbuf.c:
>
> greg@Homerw7 MINGW32 /d/dated/plplot-git/plplot-150115
> $ git log
> commit cd749d09d1f6cbad3172e1b0b04910fc8ae3f4d8
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 08:15:19 2016 -0800
>
>        more plbuf.c advances.  seqfaults when attempting to implement
> rd_data_no_copy etc.
>
> commit b4411c72cd6c75c506574699adbb6cbfe9a7f8d2
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 06:57:54 2016 -0800
>
>       see patches/0000-656am.patch.  Compiles and runs gdl test_tv
>
> commit 27096a39cfac94c988b069d3ea94dd4c11fb3848
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 06:22:52 2016 -0800
>
>       This commit brings 150115 to the edge of break, in caase of
> plsdef.c, where
>       invoking  plP_state( PLSTATE_CHR ); at line 208 or
>     possibly line 255 produces a segfault in win32 builds.
>
> commit ccfee95ac0370f00f97b0e0deeebc450545b47e1
> Author: Alan W. Irwin <ai...@us...>
> Date:   Thu Jan 15 13:22:42 2015 -0800
>
>     Build System: Fix bug for case where no display
>
> A successful test would have the above pics displayed on the terminal
> [image: Inline image 5]
>
>  The patch files below document the changes made from the base  ccfee95ac03
> git.  Using Winmerge, I compared src/ with later versions to test when a
> problem cropped up.
>
>
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

Greg said:

> On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:

>>
>> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>>
>>
>>
>> Can you describe the wrong behavior?  Does it occur when you resize?
>>
>There's no re-sizing involved.   The image is put up via
>SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
>                            0, 0, rt.bottom + 1, tv_buf.lpbitmap, &tv_buf.bi,
>DIB_RGB_COLORS);
> found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage

Hi Greg:

The fact that you need GDL to demonstrate the issue makes it extremely
difficult for us to help you with this issue.  For example, the problem
might be due to GDL not being updated properly to deal with a PLplot
change, and such an issue would be out of scope for us.

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.

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
__________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

On 2016-01-30 20:22-0800 Greg Jung wrote:

> On Fri, Jan 29, 2016 at 12:58 PM, Alan W. Irwin <ir...@be...>
> 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).

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
__________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Phil R. <p.d...@gm...>]

Hi Greg
I appreciate your frustrations. There is clearly a bug somewhere. t is
just a case of finding it and deterimining which side of the
GDL/plplot boundary it lies on - or if it is a Plplot documentation or
error checking issue. Clearly any call to plplot which results in a
segfault/crash of any sort is bad.

For some reason I can't build the gcc driver on my system (Windows
10), so I am doing this with the wxWidgets driver
>>
>> Ok I can simply build plplot without the bop() in rdbuf_bop and now I ask,
>> which example does it affect in linux?

I have just stepped through the function calls with the wxWidgets
driver in the Visual Studio debugger.The only thing that the plbop()
call at the end of rdbuf_bop() does is call plP_subpInit(), this is
because plsc->page_status is set to AT_BOP already. In this case all
that is actually done is to check that the number of sub pages in each
direction is > 0, set the current subpage to 0 and set the text and
tick mark sizes. Actually it turns out there is a bug here and the
text size is not set correctly for x03 because the orientation change
is not saved which affects the scale. I am looking to fix that now.

Regarding the specific bug with GDL and gcc driver. The gcc driver
should not actually called by the plbop() call. It would only get
called if plsc->page_status was not already AT_BOP.

Greg, can I ask what the specific call order to plplot is and how do
you end up making use of the buffer in the first place? For example do
you plot with gcc then the error occurs during a resize? Has plinit
already been called (directly or indirectly)? Do you do something a
bit more unusual such as initially set the buffer to null, do the
plotting to generate the buffer, then use plcpstrm() to copy to the
gcc driver?

Phil

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

Hi Phil,

> Greg, can I ask what the specific call order to plplot is and how do
> you end up making use of the buffer in the first place?

 I can't identify where the plot buffer is used, I thought it
was used routinely now in 5.11.

> For example do
> you plot with gcc then the error occurs during a resize?


The previous message should clarify this.  The window is holding
a mix of painted btmaps and line drawings.  somehow the bitmap gets buried.
First the line drawings are made, then Saturn image is put on via PaintImage
which calls directly SetDIBitsToDevice(hdc , ...).


> Has plinit
> already been called (directly or indirectly)? Do you do something a
> bit more unusual such as initially set the buffer to null, do the
> plotting to generate the buffer, then use plcpstrm() to copy to the
> gcc driver?

 there is no plcpstrm call in the code at all.  Images are put up directly
via SetDIBitsToDevice(hdc, ...) from an internally maintained buffer tv_buf
through GDLWINSTREAM::PaintImage and it is redrawn from ::RedrawTV()
These functionalities have only recently been adapted in the gdlwin driver.

  I think I need to expose the GDL/plplot connection, which starts at the
general
class for all GDL devices

>
>> class GDLGStream: public plstream
>
> {
>
> // protected:
>
> //   void init(); // prevent plstream::init from being called directly
>
> private:
>
>     gdlpage pageLayout;
>
>     gdlbox boxLayout;
>
>
>
> protected:
>
>   bool valid;
>
>   gdlCharInfo theCurrentChar;
>
>   gdlCharInfo theDefaultChar;
>
>   int gdlDefaultCharInitialized;
>
>   gdlbox theBox;
>
>   gdlpage thePage;
>
>   PLStream* pls;
>
>   DFloat thickFactor;
>
>
>
> public:
>
>
>>    GDLGStream( int nx, int ny, const char *driver, const char *file=NULL)
>
>     : plstream( nx, ny, driver, file), valid( true), thickFactor(1.0)
>
>   {
>
>     if (!checkPlplotDriver(driver))
>
>       ThrowGDLException(std::string("PLplot installation lacks the
>> requested driver: ") + driver);
>
>     gdlDefaultCharInitialized=0;
>
>     thePage.nbPages=0;
>
>     theBox.initialized=false;
>
>     plgpls( &pls);
>
> if (GDL_DEBUG_PLSTREAM) printf(" new GDLGstream( %d , %d , %s ):pls=%p
>> \n", nx, ny, driver, (void *)pls);
>
>
>>   }
>
>
>>  any supported device has a specifically programmed GraphicsDevice which
for windows:

>
>> class DeviceWIN : public GraphicsDevice
>
> {
>
> private:
>
> static LRESULT CALLBACK _CallWndProc(int nCode, WPARAM wParam, LPARAM
>> lParam);
>
> LRESULT CallWndProc(int nCode, WPARAM wParam, LPARAM lParam);
>
> static LRESULT CALLBACK _GetMsgProc(int nCode, WPARAM wParam, LPARAM
>> lParam);
>
> LRESULT GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam);
>
>
>>   std::vector<GDLGStream*> winList;
>
>   std::vector<long>        oList;
>
>   long oIx;
>
>   int  actWin;
>
>   int decomposed; // false -> use color table
>
> .. etc...
>
> a window needs a  specifically programmed stream class which for windows:

>
>> class GDLWINStream : public GDLGStream
>
> {
>
> private:
>
> //Atom wm_protocols;
>
> //Atom wm_delete_window;
>
> HWND refocus;
>
>
>> PLStream* pls;
>
> plstream *plst;
>
>
>> tv_buf_t tv_buf;
>
>     int _mode;
>
>     PLGraphicsIn *_gin;
>
>     POINT GinPoint;
>
>     HCURSOR CrosshairCursor;
>
>     bool rbutton, xbutton, mbutton, buttonpressed;
>
> public:
>
>     std::map<UINT, void (CALLBACK GDLWINStream::*)(UINT, WPARAM, LPARAM)>
>> msghooks;
>
>
>> GDLWINStream(int nx, int ny) :
>
> #ifdef USE_WINGDI_NOT_WINGCC
>
> GDLGStream(nx, ny, "wingdi")
>
> #else
>
> GDLGStream(nx, ny, "wingcc")
>
> #endif
>
> {
>
> pls = 0;
>
> // get the command interpreter window's handle
>
> // plsetopt("drvopt","nofocus"); // avoid stealing focus on window
>> creation
>
> // plsetopt("drvopt","text");  // use freetype fonts
>
> refocus = GetForegroundWindow();
>
> }
>
>
>> ~GDLWINStream();
>
> void Init();
>
> void EventHandler();
>
>
> so this is happening:

>
> void GDLWINStream::Init()

{

this->plstream::init();

plgpls(&pls);

#ifdef USE_WINGDI_NOT_WINGCC

#else

wingcc_Dev* dev = (wingcc_Dev *)pls->dev;

dev->waiting = 1;

#endif

UnsetFocus();

tv_buf.has_data = false;


>     HINSTANCE hInstance = (HINSTANCE)GetModuleHandle(NULL);

    CrosshairCursor = CreateCursor(hInstance, 15, 14, 32, 32,
> ANDmaskCursor, XORmaskCursor);

}


>

--------------------
So the action  goes as follows, for the WINDOW,# command;

>     bool success = actDevice->SetBackingStore(retainType);
>     success = actDevice->WOpen( wIx, title, xSize, ySize, xPos, yPos);

  bool DeviceWIN::WOpen( int wIx, const std::string& title,
>
>      int xSize, int ySize, int xPos, int yPos)
>
>   {
>
>     winList[ wIx] = new GDLWINStream( nx, ny);
>
     // set initial window size
>
    PLFLT xp; PLFLT yp;
>
    PLINT xleng; PLINT yleng;
>
    PLINT xoff; PLINT yoff;
>
    winList[ wIx]->plstream::gpage( xp, yp, xleng, yleng, xoff, yoff);
>
...

    winList[ wIx]->spage( xp, yp, xleng, yleng, xoff, yoff);


>     // no pause on win destruction

    winList[ wIx]->spause( false);

    if(debug) cout << " WOpen: ->fontld( 1) WOpen: ->scolor( ";


>     // extended fonts

    winList[ wIx]->fontld( 1);


>     // we want color

    winList[ wIx]->scolor( 1);


>

    PLINT r[256], g[256], b[256];

    actCT.Get( r, g, b);

    // winList[ wIx]->scmap0( r, g, b, actCT.size());

    winList[ wIx]->scmap1( r, g, b, ctSize);


>    if(debug) cout << "; WOpen:winList[ wIx]->Init(";


>     winList[ wIx]->Init();

   ...

   winList[ wIx]->ssub(1,1);
>
>     winList[ wIx]->adv(0);
>
>     // load font
>
>     winList[ wIx]->font( 1);
>
>     winList[ wIx]->vpor(0,1,0,1);
>
>     winList[ wIx]->wind(0,1,0,1);
>
>     winList[ wIx]->DefaultCharSize();
>
>
>


On Sun, Jan 31, 2016 at 6:51 AM, Phil Rosenberg <p.d...@gm...>
wrote:

> Hi Greg
> I appreciate your frustrations. There is clearly a bug somewhere. t is
> just a case of finding it and deterimining which side of the
> GDL/plplot boundary it lies on - or if it is a Plplot documentation or
> error checking issue. Clearly any call to plplot which results in a
> segfault/crash of any sort is bad.
>
> For some reason I can't build the gcc driver on my system (Windows
> 10), so I am doing this with the wxWidgets driver
> >>
> >> Ok I can simply build plplot without the bop() in rdbuf_bop and now I
> ask,
> >> which example does it affect in linux?
>
> I have just stepped through the function calls with the wxWidgets
> driver in the Visual Studio debugger.The only thing that the plbop()
> call at the end of rdbuf_bop() does is call plP_subpInit(), this is
> because plsc->page_status is set to AT_BOP already. In this case all
> that is actually done is to check that the number of sub pages in each
> direction is > 0, set the current subpage to 0 and set the text and
> tick mark sizes. Actually it turns out there is a bug here and the
> text size is not set correctly for x03 because the orientation change
> is not saved which affects the scale. I am looking to fix that now.
>
> Regarding the specific bug with GDL and gcc driver. The gcc driver
> should not actually called by the plbop() call. It would only get
> called if plsc->page_status was not already AT_BOP.
>
> Greg, can I ask what the specific call order to plplot is and how do
> you end up making use of the buffer in the first place? For example do
> you plot with gcc then the error occurs during a resize? Has plinit
> already been called (directly or indirectly)? Do you do something a
> bit more unusual such as initially set the buffer to null, do the
> plotting to generate the buffer, then use plcpstrm() to copy to the
> gcc driver?
>
> Phil
>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

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: Inline image 1]

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: Inline image 2]

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...@be...>
wrote:

> On 2016-01-30 20:22-0800 Greg Jung wrote:
>
> On Fri, Jan 29, 2016 at 12:58 PM, Alan W. Irwin <ir...@be...
>> >
>> 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).
>
> 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
> __________________________
>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Jim D. <ji...@di...>]

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 <gv...@gm...> 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...@be... <mailto:ir...@be...>> wrote:
> On 2016-01-30 20:22-0800 Greg Jung wrote:
> 
> On Fri, Jan 29, 2016 at 12:58 PM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>>
> 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
> __________________________
> 

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

Experimental re-build:
Keeping with 5.11.1, and re-inserting the ::c_plcear() which is in the
 winstream::Clear() routine,  called at the window creation (new
gdlsindtream, etc.)
actually does not clear the GDL image but instead put up a blank
background, and the painted
 image was again revealed when resizing.  I don't think GDL has a facility
to erase the image
at least in the win case.

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

On 2016-01-31 19:34-0800 Greg Jung 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.

Hi Greg:

I sympathize with your lack of PLplot knowledge because we have the
reverse issue here; we have very little knowledge of GDL.  So my
feeling is it is time to consult someone who is familiar with both GDL
and PLplot.  I presume that would be the guy who originally
implemented the GDL plot commands in terms of calls to the PLplot API
or someone who is continuing to maintain that GDL plotting code.  If
someone with that sort of expertise was willing to help you out, they
should be able to very quickly implement the requested test programme
by translating the group of GDL plot commands that do not work for you
into the corresponding PLplot API calls.

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
__________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Phil R. <p.d...@gm...>]

Hi All

I am doing quite a bit of speculating here, as I neither use GDL, nor
have I been involved in writing the gcc driver. However based on my
wxWidgets driver writing experience and the fact that I have used that
driver to overplot on images I think I can make a good stab at
guessing the problem.

Based on Gregs description it seems like his background images are
being covered by plplot calls. I would guess that GDL draws an image
on a device context or Window then initialises plplot passing in the
device context/window to draw on. This used to be fine, but now the
image gets covered. It seems likely that it is covered by the
plclear() call. In most drivers that call just draws a rectangle of
the background colour over the subpage. There are a few reasons why
that might now be failing
1) The image is drawn after plinit has been called. When using the
plot "fresh" this will work, but if the buffer is being used(e.g.
using plreplot) then there is no point at which the calling program
can access the canvas between all the plots so the newly added plclear
calls will draw over the original image.
2) The image was always drawn before plinit was called and the plplot
background colour was set to transparent, but the gcc behaviour of a
clear command has changed. One notable bug I introduced when working
on wxWidgets was caused because alpha is on a 0-1 scale, but rgb are
on 0-255 scales so the alpha needs converting.

As it happens there is potentially a gap in the API that is exposed
here. FIrst is that it would be good to be able to draw a rgb raster
image on a plplot - the current plimage function can't really do that.
Second for the interactive (and maybe even the noninteractive)
drivers. It might be interesting to add a callback function, basically
this puts a flag in the buffer to call a provided callback which the
user could use to render something to the canvas or provide progress
information for a plot that takes a long time to render. Or maybe this
could be a callback that could be called after every n render
operations again to provide progress information.

This also exposes a gap in our testing. I know the wxWidgets driver
can be given a canvas to draw on - in this way it actas rather like a
noninteractive driver. It seems like the gcc driver can be used in the
same way. We currently don't have any explicit tests of this usage -
although it is how I use plplot day-to-day so the wxWidgets driver is
pretty well tested in that respect.

Anyway Greg, is it possible to confirm firstly what the background
colour used by plplot is, and second where in the plplot calls the
image is drawn.

Phil


On 1 February 2016 at 08:19, Alan W. Irwin <ir...@be...> wrote:
> On 2016-01-31 19:34-0800 Greg Jung 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.
>
>
> Hi Greg:
>
> I sympathize with your lack of PLplot knowledge because we have the
> reverse issue here; we have very little knowledge of GDL.  So my
> feeling is it is time to consult someone who is familiar with both GDL
> and PLplot.  I presume that would be the guy who originally
> implemented the GDL plot commands in terms of calls to the PLplot API
> or someone who is continuing to maintain that GDL plotting code.  If
> someone with that sort of expertise was willing to help you out, they
> should be able to very quickly implement the requested test programme
> by translating the group of GDL plot commands that do not work for you
> into the corresponding PLplot API calls.
>
>
> 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
> __________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

> Anyway Greg, is it possible to confirm firstly what the background
> colour used by plplot is, and second where in the plplot calls the
> image is drawn.

 Background is normally 0,0,0 although the wine-colored plots
were explicitly set when the call was made:

> plot,findgen(32),back=88
>
That call creates the window and device context via the device driver.
without the keyword, default background is =0x000000.

The image is drawn from gdlwinstream::PaintImage; not through plplot.
Plplot has created the window and made a line graph;
 the class gdlwinstream instantiation occurs when the window is created
and the device context (dev->hdc as it is know to wingcc.c).
is passed back via pls->dev.  It is window-specific so it will be the same
hdc as was used when the line plot was made.
The gdlwinstream::paintimage() routine grabs the DC of the window and, from
its own bitmap buffer,
puts up the image using  SetDIBitsToDevice(hdc, ...) which is a MS gdi
call.

When the image goes up,
One of two things occur, depending on whether the plP_bop call is
present  at the end of rdbuf_bop:

   - [present:] wine-color background+line drawing, no image visible unless
   a move or resize
   - [not present:] black/clear background of the line drawing and for the
   image which is visible.

The line-drawing and image can appear together, they do at the end of the
rapidly-executed test.
But when the actions are made in a step-by-step fashion,

window,12 & !P.MULTI=[0,3,2] &

> plot,findgen(32),back=88
>
> ; pause a take a screenshot
>
>
[image: Inline image 1]

> TV, image,10,10,/DATA,/true,xsize=50
>
> ; pause a take a screenshot
>
>
[image: Inline image 3]

plot,findgen(32),back=88
>
> TV, image,10,10,/DATA,/true,xsize=50
>
> plot,findgen(32),back=88
>
> ; pause a take a screenshot
>
> [image: Inline image 4]

if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>
> plot,findgen(32),back=88
>
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>
> plot,findgen(32),back=88
>
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>
> plot,findgen(32),back=88
>
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>
> ; pause a take a screenshot
[image: Inline image 5]
resize and let go, take a screenshot:
[image: Inline image 6]
now do all six plots and TV calls in rapid succession and take a screenshot
directly:

window,12
!P.MULTI=[0,3,2]
for i=0,5 do begin &$
plot,findgen(32),back=88 &$
if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50 &$
end
[image: Inline image 8]


On Mon, Feb 1, 2016 at 3:11 AM, Phil Rosenberg <p.d...@gm...>
wrote:

> Hi All
>
> I am doing quite a bit of speculating here, as I neither use GDL, nor
> have I been involved in writing the gcc driver. However based on my
> wxWidgets driver writing experience and the fact that I have used that
> driver to overplot on images I think I can make a good stab at
> guessing the problem.
>
> Based on Gregs description it seems like his background images are
> being covered by plplot calls. I would guess that GDL draws an image
> on a device context or Window then initialises plplot passing in the
> device context/window to draw on. This used to be fine, but now the
> image gets covered. It seems likely that it is covered by the
> plclear() call. In most drivers that call just draws a rectangle of
> the background colour over the subpage. There are a few reasons why
> that might now be failing
> 1) The image is drawn after plinit has been called. When using the
> plot "fresh" this will work, but if the buffer is being used(e.g.
> using plreplot) then there is no point at which the calling program
> can access the canvas between all the plots so the newly added plclear
> calls will draw over the original image.
> 2) The image was always drawn before plinit was called and the plplot
> background colour was set to transparent, but the gcc behaviour of a
> clear command has changed. One notable bug I introduced when working
> on wxWidgets was caused because alpha is on a 0-1 scale, but rgb are
> on 0-255 scales so the alpha needs converting.
>
> As it happens there is potentially a gap in the API that is exposed
> here. FIrst is that it would be good to be able to draw a rgb raster
> image on a plplot - the current plimage function can't really do that.
> Second for the interactive (and maybe even the noninteractive)
> drivers. It might be interesting to add a callback function, basically
> this puts a flag in the buffer to call a provided callback which the
> user could use to render something to the canvas or provide progress
> information for a plot that takes a long time to render. Or maybe this
> could be a callback that could be called after every n render
> operations again to provide progress information.
>
> This also exposes a gap in our testing. I know the wxWidgets driver
> can be given a canvas to draw on - in this way it actas rather like a
> noninteractive driver. It seems like the gcc driver can be used in the
> same way. We currently don't have any explicit tests of this usage -
> although it is how I use plplot day-to-day so the wxWidgets driver is
> pretty well tested in that respect.
>
> Anyway Greg, is it possible to confirm firstly what the background
> colour used by plplot is, and second where in the plplot calls the
> image is drawn.
>
> Phil
>
>
> On 1 February 2016 at 08:19, Alan W. Irwin <ir...@be...>
> wrote:
> > On 2016-01-31 19:34-0800 Greg Jung 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.
> >
> >
> > Hi Greg:
> >
> > I sympathize with your lack of PLplot knowledge because we have the
> > reverse issue here; we have very little knowledge of GDL.  So my
> > feeling is it is time to consult someone who is familiar with both GDL
> > and PLplot.  I presume that would be the guy who originally
> > implemented the GDL plot commands in terms of calls to the PLplot API
> > or someone who is continuing to maintain that GDL plotting code.  If
> > someone with that sort of expertise was willing to help you out, they
> > should be able to very quickly implement the requested test programme
> > by translating the group of GDL plot commands that do not work for you
> > into the corresponding PLplot API calls.
> >
> >
> > 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
> > __________________________
>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Phil R. <p.d...@gm...>]

Hi Greg
Sorry I haven't replied earlier. Jim may have to confirm this. But it sounds like what you are aiming to do isn't really supported by Plplot. Basically it sounds like you are trying to add your own graphics commands (i.e. Draw the background) part way through a replot. Although that can work for direct drawing there is currently no way to intercept the drawing part way through. That said i think that for drivers where the user has access to the "canvas" this possibly should be supported. I also think that adding some form of drawing an rgb image would be good too. Alan do you think these are things we should consider adding to the API?

If you say that the X11 version of GDL works then it would be useful to know how that works. It may for example not be using the buffer, which allows the draws to fit wherever you want.
Can GDL catch paint events for the plot window? If so perhaps it could pass a transparent background colour to Plplot and deal with background clearing itself and draw the images at the same time.

Phil

-----Original Message-----
From: "Greg Jung" <gv...@gm...>
Sent: ‎03/‎02/‎2016 01:31
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Alan W. Irwin" <ir...@be...>; "Jim Dishaw" <ji...@di...>; "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

 
Anyway Greg, is it possible to confirm firstly what the background
colour used by plplot is, and second where in the plplot calls the
image is drawn.
 Background is normally 0,0,0 although the wine-colored plots
were explicitly set when the call was made:
plot,findgen(32),back=88

That call creates the window and device context via the device driver.
without the keyword, default background is =0x000000.


The image is drawn from gdlwinstream::PaintImage; not through plplot.
Plplot has created the window and made a line graph;
 the class gdlwinstream instantiation occurs when the window is created 
and the device context (dev->hdc as it is know to wingcc.c).
is passed back via pls->dev.  It is window-specific so it will be the same
hdc as was used when the line plot was made.  
The gdlwinstream::paintimage() routine grabs the DC of the window and, from its own bitmap buffer,
puts up the image using  SetDIBitsToDevice(hdc, ...) which is a MS gdi call.  


When the image goes up,
One of two things occur, depending on whether the plP_bop call is
present  at the end of rdbuf_bop:
[present:] wine-color background+line drawing, no image visible unless a move or resize

[not present:] black/clear background of the line drawing and for the image which is visible.
The line-drawing and image can appear together, they do at the end of the rapidly-executed test.
But when the actions are made in a step-by-step fashion, 


window,12 & !P.MULTI=[0,3,2] & 

plot,findgen(32),back=88
; pause a take a screenshot




TV, image,10,10,/DATA,/true,xsize=50
; pause a take a screenshot






plot,findgen(32),back=88
TV, image,10,10,/DATA,/true,xsize=50
plot,findgen(32),back=88
; pause a take a screenshot
 


if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
plot,findgen(32),back=88
if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
plot,findgen(32),back=88
if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
plot,findgen(32),back=88
if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
; pause a take a screenshot 


resize and let go, take a screenshot:


now do all six plots and TV calls in rapid succession and take a screenshot directly:
window,12
!P.MULTI=[0,3,2]
for i=0,5 do begin &$
plot,findgen(32),back=88 &$
if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50 &$
end




On Mon, Feb 1, 2016 at 3:11 AM, Phil Rosenberg <p.d...@gm...> wrote:

Hi All

I am doing quite a bit of speculating here, as I neither use GDL, nor
have I been involved in writing the gcc driver. However based on my
wxWidgets driver writing experience and the fact that I have used that
driver to overplot on images I think I can make a good stab at
guessing the problem.

Based on Gregs description it seems like his background images are
being covered by plplot calls. I would guess that GDL draws an image
on a device context or Window then initialises plplot passing in the
device context/window to draw on. This used to be fine, but now the
image gets covered. It seems likely that it is covered by the
plclear() call. In most drivers that call just draws a rectangle of
the background colour over the subpage. There are a few reasons why
that might now be failing
1) The image is drawn after plinit has been called. When using the
plot "fresh" this will work, but if the buffer is being used(e.g.
using plreplot) then there is no point at which the calling program
can access the canvas between all the plots so the newly added plclear
calls will draw over the original image.
2) The image was always drawn before plinit was called and the plplot
background colour was set to transparent, but the gcc behaviour of a
clear command has changed. One notable bug I introduced when working
on wxWidgets was caused because alpha is on a 0-1 scale, but rgb are
on 0-255 scales so the alpha needs converting.

As it happens there is potentially a gap in the API that is exposed
here. FIrst is that it would be good to be able to draw a rgb raster
image on a plplot - the current plimage function can't really do that.
Second for the interactive (and maybe even the noninteractive)
drivers. It might be interesting to add a callback function, basically
this puts a flag in the buffer to call a provided callback which the
user could use to render something to the canvas or provide progress
information for a plot that takes a long time to render. Or maybe this
could be a callback that could be called after every n render
operations again to provide progress information.

This also exposes a gap in our testing. I know the wxWidgets driver
can be given a canvas to draw on - in this way it actas rather like a
noninteractive driver. It seems like the gcc driver can be used in the
same way. We currently don't have any explicit tests of this usage -
although it is how I use plplot day-to-day so the wxWidgets driver is
pretty well tested in that respect.

Anyway Greg, is it possible to confirm firstly what the background
colour used by plplot is, and second where in the plplot calls the
image is drawn.

Phil



On 1 February 2016 at 08:19, Alan W. Irwin <ir...@be...> wrote:
> On 2016-01-31 19:34-0800 Greg Jung 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.
>
>
> Hi Greg:
>
> I sympathize with your lack of PLplot knowledge because we have the
> reverse issue here; we have very little knowledge of GDL.  So my
> feeling is it is time to consult someone who is familiar with both GDL
> and PLplot.  I presume that would be the guy who originally
> implemented the GDL plot commands in terms of calls to the PLplot API
> or someone who is continuing to maintain that GDL plotting code.  If
> someone with that sort of expertise was willing to help you out, they
> should be able to very quickly implement the requested test programme
> by translating the group of GDL plot commands that do not work for you
> into the corresponding PLplot API calls.
>
>
> 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
> __________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Jim D. <ji...@di...>]

> On Feb 6, 2016, at 5:09 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Greg
> Sorry I haven't replied earlier. Jim may have to confirm this. But it sounds like what you are aiming to do isn't really supported by Plplot. Basically it sounds like you are trying to add your own graphics commands (i.e. Draw the background) part way through a replot. Although that can work for direct drawing there is currently no way to intercept the drawing part way through. That said i think that for drivers where the user has access to the "canvas" this possibly should be supported. I also think that adding some form of drawing an rgb image would be good too. Alan do you think these are things we should consider adding to the API?
> 

If I understand what is wanted, an API change would be needed. It could be implemented with a "call external handler" command that interrupts the drawing and executes a list of callback functions. The command would take an argument a tag, which would allow for multiple interruptions. 

The only issue is that I don't see this working on non-gui drivers in a clean way. Also, it would not work on saved plot metafiles (which I apologize for not having finished yet). 

> If you say that the X11 version of GDL works then it would be useful to know how that works. It may for example not be using the buffer, which allows the draws to fit wherever you want.
> Can GDL catch paint events for the plot window? If so perhaps it could pass a transparent background colour to Plplot and deal with background clearing itself and draw the images at the same time.
> 
> Phil
> From: Greg Jung
> Sent: ‎03/‎02/‎2016 01:31
> To: Phil Rosenberg
> Cc: Alan W. Irwin; Jim Dishaw; plp...@li...
> Subject: Re: [Plplot-devel] plP_bop() was killing functionality in wingcc
> 
>  
>> Anyway Greg, is it possible to confirm firstly what the background
>> colour used by plplot is, and second where in the plplot calls the
>> image is drawn.
>  Background is normally 0,0,0 although the wine-colored plots
> were explicitly set when the call was made:
>> plot,findgen(32),back=88
> That call creates the window and device context via the device driver.
> without the keyword, default background is =0x000000.
> 
> The image is drawn from gdlwinstream::PaintImage; not through plplot.
> Plplot has created the window and made a line graph;
>  the class gdlwinstream instantiation occurs when the window is created 
> and the device context (dev->hdc as it is know to wingcc.c).
> is passed back via pls->dev.  It is window-specific so it will be the same
> hdc as was used when the line plot was made.  
> The gdlwinstream::paintimage() routine grabs the DC of the window and, from its own bitmap buffer,
> puts up the image using  SetDIBitsToDevice(hdc, ...) which is a MS gdi call.  
> 
> When the image goes up,
> One of two things occur, depending on whether the plP_bop call is
> present  at the end of rdbuf_bop:
> [present:] wine-color background+line drawing, no image visible unless a move or resize
> [not present:] black/clear background of the line drawing and for the image which is visible.
> The line-drawing and image can appear together, they do at the end of the rapidly-executed test.
> But when the actions are made in a step-by-step fashion, 
> 
> window,12 & !P.MULTI=[0,3,2] & 
>>> plot,findgen(32),back=88
>>> ; pause a take a screenshot
> 
> <image.png>
>>> TV, image,10,10,/DATA,/true,xsize=50
>>> ; pause a take a screenshot
> 
> <image.png>
> 
>>> plot,findgen(32),back=88
>>> TV, image,10,10,/DATA,/true,xsize=50
>>> plot,findgen(32),back=88
>>> ; pause a take a screenshot
> <image.png> 
> 
>>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>> plot,findgen(32),back=88
>>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>> plot,findgen(32),back=88
>>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>> plot,findgen(32),back=88
>>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
> ; pause a take a screenshot 
> <image.png>
> resize and let go, take a screenshot:
> <image.png>
> now do all six plots and TV calls in rapid succession and take a screenshot directly:
> window,12
> !P.MULTI=[0,3,2]
> for i=0,5 do begin &$
> plot,findgen(32),back=88 &$
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50 &$
> end
> <image.png>
> 
>> On Mon, Feb 1, 2016 at 3:11 AM, Phil Rosenberg <p.d...@gm...> wrote:
>> Hi All
>> 
>> I am doing quite a bit of speculating here, as I neither use GDL, nor
>> have I been involved in writing the gcc driver. However based on my
>> wxWidgets driver writing experience and the fact that I have used that
>> driver to overplot on images I think I can make a good stab at
>> guessing the problem.
>> 
>> Based on Gregs description it seems like his background images are
>> being covered by plplot calls. I would guess that GDL draws an image
>> on a device context or Window then initialises plplot passing in the
>> device context/window to draw on. This used to be fine, but now the
>> image gets covered. It seems likely that it is covered by the
>> plclear() call. In most drivers that call just draws a rectangle of
>> the background colour over the subpage. There are a few reasons why
>> that might now be failing
>> 1) The image is drawn after plinit has been called. When using the
>> plot "fresh" this will work, but if the buffer is being used(e.g.
>> using plreplot) then there is no point at which the calling program
>> can access the canvas between all the plots so the newly added plclear
>> calls will draw over the original image.
>> 2) The image was always drawn before plinit was called and the plplot
>> background colour was set to transparent, but the gcc behaviour of a
>> clear command has changed. One notable bug I introduced when working
>> on wxWidgets was caused because alpha is on a 0-1 scale, but rgb are
>> on 0-255 scales so the alpha needs converting.
>> 
>> As it happens there is potentially a gap in the API that is exposed
>> here. FIrst is that it would be good to be able to draw a rgb raster
>> image on a plplot - the current plimage function can't really do that.
>> Second for the interactive (and maybe even the noninteractive)
>> drivers. It might be interesting to add a callback function, basically
>> this puts a flag in the buffer to call a provided callback which the
>> user could use to render something to the canvas or provide progress
>> information for a plot that takes a long time to render. Or maybe this
>> could be a callback that could be called after every n render
>> operations again to provide progress information.
>> 
>> This also exposes a gap in our testing. I know the wxWidgets driver
>> can be given a canvas to draw on - in this way it actas rather like a
>> noninteractive driver. It seems like the gcc driver can be used in the
>> same way. We currently don't have any explicit tests of this usage -
>> although it is how I use plplot day-to-day so the wxWidgets driver is
>> pretty well tested in that respect.
>> 
>> Anyway Greg, is it possible to confirm firstly what the background
>> colour used by plplot is, and second where in the plplot calls the
>> image is drawn.
>> 
>> Phil
>> 
>> 
>> On 1 February 2016 at 08:19, Alan W. Irwin <ir...@be...> wrote:
>> > On 2016-01-31 19:34-0800 Greg Jung 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.
>> >
>> >
>> > Hi Greg:
>> >
>> > I sympathize with your lack of PLplot knowledge because we have the
>> > reverse issue here; we have very little knowledge of GDL.  So my
>> > feeling is it is time to consult someone who is familiar with both GDL
>> > and PLplot.  I presume that would be the guy who originally
>> > implemented the GDL plot commands in terms of calls to the PLplot API
>> > or someone who is continuing to maintain that GDL plotting code.  If
>> > someone with that sort of expertise was willing to help you out, they
>> > should be able to very quickly implement the requested test programme
>> > by translating the group of GDL plot commands that do not work for you
>> > into the corresponding PLplot API calls.
>> >
>> >
>> > 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
>> > __________________________
> 
> <image.png>
> <image.png>
> <image.png>
> <image.png>
> <image.png>
> <image.png>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

Hi guys,
  Yes its clear now the rgb pic doesn't really fit into the plplot scheme
and how
it gets up is a device-dependent thing.  In the xwin case the bitmap is
accessed through the xlib calls; the win case created a separate bitmap.
It does benefit from the absence of the plP_bop() call, so it would be nice
to know what side effects I can expect from deleting this line.

Greg

On Sat, Feb 6, 2016 at 5:54 AM, Jim Dishaw <ji...@di...> wrote:

>
> On Feb 6, 2016, at 5:09 AM, Phil Rosenberg <p.d...@gm...>
> wrote:
>
> Hi Greg
> Sorry I haven't replied earlier. Jim may have to confirm this. But it
> sounds like what you are aiming to do isn't really supported by Plplot.
> Basically it sounds like you are trying to add your own graphics commands
> (i.e. Draw the background) part way through a replot. Although that can
> work for direct drawing there is currently no way to intercept the drawing
> part way through. That said i think that for drivers where the user has
> access to the "canvas" this possibly should be supported. I also think that
> adding some form of drawing an rgb image would be good too. Alan do you
> think these are things we should consider adding to the API?
>
>
> If I understand what is wanted, an API change would be needed. It could be
> implemented with a "call external handler" command that interrupts the
> drawing and executes a list of callback functions. The command would take
> an argument a tag, which would allow for multiple interruptions.
>
> The only issue is that I don't see this working on non-gui drivers in a
> clean way. Also, it would not work on saved plot metafiles (which I
> apologize for not having finished yet).
>
> If you say that the X11 version of GDL works then it would be useful to
> know how that works. It may for example not be using the buffer, which
> allows the draws to fit wherever you want.
> Can GDL catch paint events for the plot window? If so perhaps it could
> pass a transparent background colour to Plplot and deal with background
> clearing itself and draw the images at the same time.
>
> Phil
> ------------------------------
> From: Greg Jung <gv...@gm...>
> Sent: ‎03/‎02/‎2016 01:31
> To: Phil Rosenberg <p.d...@gm...>
> Cc: Alan W. Irwin <ir...@be...>; Jim Dishaw <ji...@di...>;
> plp...@li...
> Subject: Re: [Plplot-devel] plP_bop() was killing functionality in wingcc
>
>
>
>> Anyway Greg, is it possible to confirm firstly what the background
>> colour used by plplot is, and second where in the plplot calls the
>> image is drawn.
>
>  Background is normally 0,0,0 although the wine-colored plots
> were explicitly set when the call was made:
>
>> plot,findgen(32),back=88
>>
> That call creates the window and device context via the device driver.
> without the keyword, default background is =0x000000.
>
> The image is drawn from gdlwinstream::PaintImage; not through plplot.
> Plplot has created the window and made a line graph;
>  the class gdlwinstream instantiation occurs when the window is created
> and the device context (dev->hdc as it is know to wingcc.c).
> is passed back via pls->dev.  It is window-specific so it will be the same
> hdc as was used when the line plot was made.
> The gdlwinstream::paintimage() routine grabs the DC of the window and,
> from its own bitmap buffer,
> puts up the image using  SetDIBitsToDevice(hdc, ...) which is a MS gdi
> call.
>
> When the image goes up,
> One of two things occur, depending on whether the plP_bop call is
> present  at the end of rdbuf_bop:
>
>    - [present:] wine-color background+line drawing, no image visible
>    unless a move or resize
>    - [not present:] black/clear background of the line drawing and for
>    the image which is visible.
>
> The line-drawing and image can appear together, they do at the end of the
> rapidly-executed test.
> But when the actions are made in a step-by-step fashion,
>
> window,12 & !P.MULTI=[0,3,2] &
>
>> plot,findgen(32),back=88
>>
>> ; pause a take a screenshot
>>
>>
> <image.png>
>
>> TV, image,10,10,/DATA,/true,xsize=50
>>
>> ; pause a take a screenshot
>>
>>
> <image.png>
>
> plot,findgen(32),back=88
>>
>> TV, image,10,10,/DATA,/true,xsize=50
>>
>> plot,findgen(32),back=88
>>
>> ; pause a take a screenshot
>>
>> <image.png>
>
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>
>> plot,findgen(32),back=88
>>
>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>
>> plot,findgen(32),back=88
>>
>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>
>> plot,findgen(32),back=88
>>
>> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50
>>
>> ; pause a take a screenshot
> <image.png>
> resize and let go, take a screenshot:
> <image.png>
> now do all six plots and TV calls in rapid succession and take a
> screenshot directly:
>
> window,12
> !P.MULTI=[0,3,2]
> for i=0,5 do begin &$
> plot,findgen(32),back=88 &$
> if magick_exists() then TV, image,10,10,/DATA,/true,xsize=50 &$
> end
> <image.png>
>
>
> On Mon, Feb 1, 2016 at 3:11 AM, Phil Rosenberg <p.d...@gm...>
> wrote:
>
>> Hi All
>>
>> I am doing quite a bit of speculating here, as I neither use GDL, nor
>> have I been involved in writing the gcc driver. However based on my
>> wxWidgets driver writing experience and the fact that I have used that
>> driver to overplot on images I think I can make a good stab at
>> guessing the problem.
>>
>> Based on Gregs description it seems like his background images are
>> being covered by plplot calls. I would guess that GDL draws an image
>> on a device context or Window then initialises plplot passing in the
>> device context/window to draw on. This used to be fine, but now the
>> image gets covered. It seems likely that it is covered by the
>> plclear() call. In most drivers that call just draws a rectangle of
>> the background colour over the subpage. There are a few reasons why
>> that might now be failing
>> 1) The image is drawn after plinit has been called. When using the
>> plot "fresh" this will work, but if the buffer is being used(e.g.
>> using plreplot) then there is no point at which the calling program
>> can access the canvas between all the plots so the newly added plclear
>> calls will draw over the original image.
>> 2) The image was always drawn before plinit was called and the plplot
>> background colour was set to transparent, but the gcc behaviour of a
>> clear command has changed. One notable bug I introduced when working
>> on wxWidgets was caused because alpha is on a 0-1 scale, but rgb are
>> on 0-255 scales so the alpha needs converting.
>>
>> As it happens there is potentially a gap in the API that is exposed
>> here. FIrst is that it would be good to be able to draw a rgb raster
>> image on a plplot - the current plimage function can't really do that.
>> Second for the interactive (and maybe even the noninteractive)
>> drivers. It might be interesting to add a callback function, basically
>> this puts a flag in the buffer to call a provided callback which the
>> user could use to render something to the canvas or provide progress
>> information for a plot that takes a long time to render. Or maybe this
>> could be a callback that could be called after every n render
>> operations again to provide progress information.
>>
>> This also exposes a gap in our testing. I know the wxWidgets driver
>> can be given a canvas to draw on - in this way it actas rather like a
>> noninteractive driver. It seems like the gcc driver can be used in the
>> same way. We currently don't have any explicit tests of this usage -
>> although it is how I use plplot day-to-day so the wxWidgets driver is
>> pretty well tested in that respect.
>>
>> Anyway Greg, is it possible to confirm firstly what the background
>> colour used by plplot is, and second where in the plplot calls the
>> image is drawn.
>>
>> Phil
>>
>>
>> On 1 February 2016 at 08:19, Alan W. Irwin <ir...@be...>
>> wrote:
>> > On 2016-01-31 19:34-0800 Greg Jung 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.
>> >
>> >
>> > Hi Greg:
>> >
>> > I sympathize with your lack of PLplot knowledge because we have the
>> > reverse issue here; we have very little knowledge of GDL.  So my
>> > feeling is it is time to consult someone who is familiar with both GDL
>> > and PLplot.  I presume that would be the guy who originally
>> > implemented the GDL plot commands in terms of calls to the PLplot API
>> > or someone who is continuing to maintain that GDL plotting code.  If
>> > someone with that sort of expertise was willing to help you out, they
>> > should be able to very quickly implement the requested test programme
>> > by translating the group of GDL plot commands that do not work for you
>> > into the corresponding PLplot API calls.
>> >
>> >
>> > 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
>> > __________________________
>>
>
> <image.png>
>
> <image.png>
>
> <image.png>
>
> <image.png>
>
> <image.png>
>
> <image.png>
>
>