plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] RGBA background images

[Douglas H. <dh...@uc...>]

Hi all:  I achieve something like this, IE plotting on top of the image 
of a map, with perl/PDL and the plplot MEM driver.
I first use a PDL plotting routine to create an RGB memory image to pass 
to the MEM driver.

I'm not sure if this is exactly what you want, but it might help.

--Doug

On 2/6/16 2:28 PM, Alan W. Irwin wrote:
> On 2016-02-06 10:09-0000 Phil Rosenberg 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?
>
> Hi Phil:
>
> If you are talking about the goal of having potentially different RGBA
> images for each different page's background, then I really like that
> long-term goal because you can get some really cool effects that way.
> But I am concerned about the speed since it currently takes us an
> extremely long time to display even a low-resolution image for example
> 20. So I encourage you to think about the image display speed issue.
> For example, I presume many of our device drivers (e.g., cairo, qt,
> and wxwidgets) potentially could display an image using the
> (presumably fast) capabilities of the underlying pango/cairo, Qt[45],
> and wxwidgets libraries.  So I think one potential way forward is to
> implement that "native" image rendering capability in each of those
> device drivers (and others as well whose underlying library has the
> native capability).  Then plimage lets the driver render the image if
> the driver advertises it has the capability, and otherwise falls back
> to the extremely slow current method of displaying images.
>
> Meanwhile, I have thought of a closely related topic concerning the
> "A" in "RGBA" which I would like to discuss which is how to improve
> our current methods of handling uniformly coloured semitransparent
> backgrounds. But I will present my thoughts on that topic in a
> separate thread so as not to hijack this one.
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> 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=272487151&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Uniformly coloured semitransparent backgrounds

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

Hi Alan
There is plenty of cool stuff there, but remembering that plplot is a library and not an application our job should be to enable transparency and allow the user to do that cool stuff - but that might form the basis of a demo.

Here is my opinion:
For file output, it should just be like a transparent/semitransparent rectangle was drawn over the page as the first render object.
For drivers where the user provides the canvas, things should be just as for file output. This would allow users to draw over existing items - I'm thinking, e.g. A report program that includes text and provides this dc to plplot to draw plots on too.
For interactive drivers where the user does not provide the canvas I am not sure what to do. In this case I think the most appropriate thing is to ignore transparency. I don't think making the window transparent is appropriate as it will just generate lots of driver and platform dependant inconsistencies.

Regarding page clears. I feel that a new page is a new page and should not show previous pages in the background. Presumably this is dealt with by new files or document pages in many cases. If users want to simulate this effect they can do so themselves using plclear calls with semitransparent background colours.

I think all this will then be consistent with transparent lines and shapes rendered by other calls.

Phil


-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎06/‎02/‎2016 22:00
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Greg Jung" <gv...@gm...>; "Jim Dishaw" <ji...@di...>; "plp...@li..." <plp...@li...>
Subject: Uniformly coloured semitransparent backgrounds

Hi Phil:

Part of the overall goal of getting RGBA background images to work is
to get the "A" (alpha channel) component of that to work properly, and
so a preliminary goal should be to implement uniformly colored
semitransparent backgrounds correctly.


Some current semitransparent background issues we should be aware of:

* Device driver issues:

Just for a single page plot where I specify a completely transparent
background, there are issues for a number of our devices.  Ones that
apparently do work currently are the qt devices.  For example,

examples/c/x00c -dev pdfqt -bg 000000_0.0 -o test.pdf

does produce a transparent background for that pdf as proved by the
ImageMagick "display" command rendering that transparent background as
a checkerboard.  But the same experiment with pdfcairo shows an opaque
white background. I believe that should be considered to be a bug in
the cairo devices since the fundamental principle should be if a user
specifies a semitransparent background (as above), that is exactly
what PLplot drivers should supply rather than substituting something
else in the belief that we know better than the user!

* Interactive device issues:

Even though the above experiment with pdfqt demonstrates that device
follows the user wishes, it is not clear that also occurs for the
qtwidget device because I could not get the desired result
(a completely transparent background) to work for qtwidget.  Of
course, that may have nothing to do with our qt device
and may be related to the following compositing issue.

* Desktop compositing issues:

There is an ImageMagick "display" option to actually honor the
transparent background request rather than replacing it with a
checkboard.  I cannot remember that exact option, but when I tried it
years ago, the result was the plot is displayed on top of whatever
your desktop would be displaying otherwise (what I call the root
desktop below). But it would be cooler still if it worked for
semitransparent backgrounds (as opposed to completely transparent like
in the above case), but when I last tried this there were KDE/X
compositing issues that didn't allow that to work properly.  I have no
idea whether my KDE/X desktop software has been fixed yet in this
regard or not.

* Multiple page issues:

I can forsee the need for two modes here for those interactive cases
where pages are normally just stacked on top of the previous pages
with a background superimposed at the start and between each page. If
that background is completely transparent, then you should see the
whole stack of previous results right back to the root desktop
(whatever the desktop software would be displaying if the plot GUI was
not superimposed on top), and if the transparency is dropped to say 90
per cent then you will see that stack of previous results gradually
fading away as you display contents from deeper in the stack to make a
really cool-looking effect.  So this possibility of seeing everything
in the stack modified by the transparency of the superimposed
backgrounds in between should be allowed, but there should also be an
interactive mode that starts fresh with each page, i.e., the root
desktop is displayed, then the semitransparent background, then the
plot for the single page.

In sum, this whole field of supporting RGBA background images for each
plot page is an extremely interesting one, but to get the "A" part of
that to work correctly we need to deal with the above issues that show
up even when the background "RGBA image" is a simple one that is
uniformly coloured.

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
__________________________


__________________________
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] CMake minimum version has just been bumped

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

On 2016-02-06 23:09-0800 Greg Jung wrote:

> I'd like to make a pitch for maintaining a lower general cmake minimum
> until
> more compelling  bug fixes or features are introduced.
> I have over 6 platforms standardized on cmake 3.3.2.
> Maybe the new version requirement should be restricted to those platforms
> where they are needed?  And an update message issued for those that are
> not required to update? (i.e. "cmake 3.6.2 looks really spiffy; try it and
> avoid
> seeing this annoying message!")

Hi Greg:

It is a difficult value judgement to decide how close to the CMake
cutting edge we should be for our minimum version.  From my
build-system developer perspective it is good to stay close to the
cutting edge since that minimizes the restrictions we have on taking
advantage of bug fixes and new features that are constantly being
developed for CMake.  Also, self-diagnosis is much better for later
CMake versions so tests of our build system on all platforms using
cutting-edge CMake helps to reduce problematic CMake logic in our
build system.

But it is definitely convenient for our Linux users and other
platforms like Cygwin that offer cmake as part of a coherent
distribution of free software that we support a much older version of
CMake as well.  So that is why we support CMake 3.0.2 for Linux and
Cygwin, but I am not really happy with that compromise since it forces
us to work around some bugs/misfeatures in 3.0.2 that have long since
been fixed in 3.3.2. For that reason I am definitely looking forward
to bumping our Linux minimum to 3.3.2 just as soon as most Linux
distributions offer that version or higher.  And similar arguments can
be made for Cygwin and possibly MinGW-w64/MSYS2.

On the other hand, for those users who are using platforms such as
MSVC _without_ a coherent free software distribution, my thought is
they are going to have to build (or download from Kitware) a CMake
version in any case so why not ask such users to use the latest
matured version?

This, of course, assumes our build system has been changed so that it
works well with the latest matured version (although in the present
case of the bump from the matured 3.3 to matured 3.4, i.e., from 3.3.2
to 3.4.3, no such build system changes were necessary).  Note, that a
new minor version of CMake, e.g., the 0, 1, 2, etc., in 3.0, 3.1, 3.2
etc. is released every 3 months or so that is the rough interval
between when matured versions are released, e.g., between 3.3.2 and
3.4.3.  So we assume that 3-month interval below.

Anyhow, I don't think we are asking too much of our MSVC users (and
users of other platforms without a coherent free software
distribution) to download or build CMake every 3 months or so as
3.3.z, 3.4.z, etc., mature. Note, I am not asking you to do that for
your Linux and Cygwin platforms, and I could add MinGW-w64/MSYS2 to
the list of platforms where 3.0.2 is the minimum version as well if
you think that is desireable.

So my question for you is do you really think it is going to be that
onerous for you to move from 3.3.2 to 3.4.3 just for MSVC and
classical MinGW/MSYS? After all, I have already given 3.4.3 a pretty
good thrashing on Linux so I expect there is an excellent chance it
will be reliable for all your various platform needs as well.

Finally, note that if you convince me to go with the second latest
mature version (i.e., 3.3.2 now rather than 3.4.3) it will give you a
3-month break, but then after that, keeping up with second latest
mature version will still require you to build/download CMake every 3
months or so.  So why not go with latest mature rather than second
latest if they are essentially going to be the same trouble for you?

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] RGBA background images

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

Hi Alan
Yes, but not just as background images, as plot images too. For example I have in the past used plplot to overplot wind vectors from a weather model on satellite views of the earth. So I would want an API call where I set the world coordinates of the top left and bottom right corners of the image and plplot draws it cropped to the viewport. A similar API call for rendering to the subpage and the page would be good.

There are transparency issues that I will add to the other thread, because they only occur if the background it transparent.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎06/‎02/‎2016 21:28
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Greg Jung" <gv...@gm...>; "Jim Dishaw" <ji...@di...>; "plp...@li..." <plp...@li...>
Subject: RGBA background images

On 2016-02-06 10:09-0000 Phil Rosenberg 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?

Hi Phil:

If you are talking about the goal of having potentially different RGBA
images for each different page's background, then I really like that
long-term goal because you can get some really cool effects that way.
But I am concerned about the speed since it currently takes us an
extremely long time to display even a low-resolution image for example
20. So I encourage you to think about the image display speed issue.
For example, I presume many of our device drivers (e.g., cairo, qt,
and wxwidgets) potentially could display an image using the
(presumably fast) capabilities of the underlying pango/cairo, Qt[45],
and wxwidgets libraries.  So I think one potential way forward is to
implement that "native" image rendering capability in each of those
device drivers (and others as well whose underlying library has the
native capability).  Then plimage lets the driver render the image if
the driver advertises it has the capability, and otherwise falls back
to the extremely slow current method of displaying images.

Meanwhile, I have thought of a closely related topic concerning the
"A" in "RGBA" which I would like to discuss which is how to improve
our current methods of handling uniformly coloured semitransparent
backgrounds. But I will present my thoughts on that topic in a
separate thread so as not to hijack this one.

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] CMake minimum version has just been bumped

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

I'd like to make a pitch for maintaining a lower general cmake minimum
until
more compelling  bug fixes or features are introduced.
 I have over 6 platforms standardized on cmake 3.3.2.
Maybe the new version requirement should be restricted to those platforms
where they are needed?  And an update message issued for those that are
not required to update? (i.e. "cmake 3.6.2 looks really spiffy; try it and
avoid
seeing this annoying message!")

Greg


On Sat, Feb 6, 2016 at 9:53 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-12-10 11:17-0800 Alan W. Irwin wrote:
>
> > On 2015-12-10 10:54-0000 Phil Rosenberg wrote:
> >
> >> Hi Alan
> >> This is just a note about cmake version bumping. You have been
> >> increasing the required CMake version lately, which I generally have
> >> no problem with, however CMake 3.4.1 seems to have a major issue on
> >> Windows, in that it cannot seem to find the latest visual studio
> >> compiler (which happens to be the version I am using). I reported a
> >> bug and it has been marked as a duplicate of another bug reported
> >> early November (https://cmake.org/Bug/view.php?id=15831). Therefore
> >> can I ask that until this bug is fixed we do not bump up any further.
> >
> > Agreed.
>
> Hi Phil:
>
> I notice at <https://cmake.org/Bug/view.php?id=15831> that this bug
> has been marked as fixed for 3.4.2, and one other key Windows fix was
> recently made for 3.4.3.  So that appears to satisfy the request
> you made above.
>
> Therefore (as of commit 640fd5c) I bumped the minimum CMake version to
> 3.4.3 for all PLplot platforms (other than Linux and Cygwin where will
> still use 3.0.2 as the minimum version).  Please see the commit
> message for all the successful tests I did of CMake-3.4.3 on Linux.
>
> However, if you discover any regression of CMake-3.4.3 compared to
> CMake-3.3.2 (the previous minimum version) let me know, and I will
> either adjust our build system to be more in tune with 3.4.3 or else
> revert the changes in commit 640fd5c until we can figure out what is
> wrong for the 3.4.3 case.
>
> Note, the next release of CMake after 3.4.3 is going to be 3.5.0. A
> release candidate (3.5.0-rc1) has been distributed for that, but I
> haven't bothered to try it since it appears there are a whole host of
> problems for that release candidate.  But since 3.4.3 was such a
> success for me, and to help out the CMake developers, I am going to
> try one of the later release candidates for 3.5.0 just to investigate
> whether there are any showstopper CMake-3.5.0-rc? bugs found by the
> PLplot build to report to the CMake developers.
>
> 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
> __________________________
>
>
> ------------------------------------------------------------------------------
> 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=272487151&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Am I using eop() or abusing it?

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

GDL has had a problem in its use of the wingcc driver in that,
plotting additions to a basic PLOT call do not stick to the plot
 when it is moved or resized.  I've found that when I stick another
eop() call after each of these plot calls, the problem is "solved"
for this driver https://sourceforge.net/p/gnudatalanguage/bugs/689/#b1d7
because each eop() in wingcc induces another copy of the screen to the
 bitmap used for refresh.

  Jim's new wingdi driver doesn't have this issue although I can't see why
not.

According to the plplot-5.10 doc, eop() would close a plot file begun when
bop()
is called.  Currently rdbuf_eop() is a no-op although there is an EOP code
put
into the plot buffer.

My happy answer would be that a second eop() without bop() indicates a
re-open, "append" to the ongoing plot buffer (or file).  Is that consistent
with current usage?

Thanks,
Greg

[Plplot-devel] CMake minimum version has just been bumped

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

On 2015-12-10 11:17-0800 Alan W. Irwin wrote:

> On 2015-12-10 10:54-0000 Phil Rosenberg wrote:
>
>> Hi Alan
>> This is just a note about cmake version bumping. You have been
>> increasing the required CMake version lately, which I generally have
>> no problem with, however CMake 3.4.1 seems to have a major issue on
>> Windows, in that it cannot seem to find the latest visual studio
>> compiler (which happens to be the version I am using). I reported a
>> bug and it has been marked as a duplicate of another bug reported
>> early November (https://cmake.org/Bug/view.php?id=15831). Therefore
>> can I ask that until this bug is fixed we do not bump up any further.
>
> Agreed.

Hi Phil:

I notice at <https://cmake.org/Bug/view.php?id=15831> that this bug
has been marked as fixed for 3.4.2, and one other key Windows fix was
recently made for 3.4.3.  So that appears to satisfy the request
you made above.

Therefore (as of commit 640fd5c) I bumped the minimum CMake version to
3.4.3 for all PLplot platforms (other than Linux and Cygwin where will
still use 3.0.2 as the minimum version).  Please see the commit
message for all the successful tests I did of CMake-3.4.3 on Linux.

However, if you discover any regression of CMake-3.4.3 compared to
CMake-3.3.2 (the previous minimum version) let me know, and I will
either adjust our build system to be more in tune with 3.4.3 or else
revert the changes in commit 640fd5c until we can figure out what is
wrong for the 3.4.3 case.

Note, the next release of CMake after 3.4.3 is going to be 3.5.0. A
release candidate (3.5.0-rc1) has been distributed for that, but I
haven't bothered to try it since it appears there are a whole host of
problems for that release candidate.  But since 3.4.3 was such a
success for me, and to help out the CMake developers, I am going to
try one of the later release candidates for 3.5.0 just to investigate
whether there are any showstopper CMake-3.5.0-rc? bugs found by the
PLplot build to report to the CMake developers.

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
__________________________

[Plplot-devel] Uniformly coloured semitransparent backgrounds

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

Hi Phil:

Part of the overall goal of getting RGBA background images to work is
to get the "A" (alpha channel) component of that to work properly, and
so a preliminary goal should be to implement uniformly colored
semitransparent backgrounds correctly.


Some current semitransparent background issues we should be aware of:

* Device driver issues:

Just for a single page plot where I specify a completely transparent
background, there are issues for a number of our devices.  Ones that
apparently do work currently are the qt devices.  For example,

examples/c/x00c -dev pdfqt -bg 000000_0.0 -o test.pdf

does produce a transparent background for that pdf as proved by the
ImageMagick "display" command rendering that transparent background as
a checkerboard.  But the same experiment with pdfcairo shows an opaque
white background. I believe that should be considered to be a bug in
the cairo devices since the fundamental principle should be if a user
specifies a semitransparent background (as above), that is exactly
what PLplot drivers should supply rather than substituting something
else in the belief that we know better than the user!

* Interactive device issues:

Even though the above experiment with pdfqt demonstrates that device
follows the user wishes, it is not clear that also occurs for the
qtwidget device because I could not get the desired result
(a completely transparent background) to work for qtwidget.  Of
course, that may have nothing to do with our qt device
and may be related to the following compositing issue.

* Desktop compositing issues:

There is an ImageMagick "display" option to actually honor the
transparent background request rather than replacing it with a
checkboard.  I cannot remember that exact option, but when I tried it
years ago, the result was the plot is displayed on top of whatever
your desktop would be displaying otherwise (what I call the root
desktop below). But it would be cooler still if it worked for
semitransparent backgrounds (as opposed to completely transparent like
in the above case), but when I last tried this there were KDE/X
compositing issues that didn't allow that to work properly.  I have no
idea whether my KDE/X desktop software has been fixed yet in this
regard or not.

* Multiple page issues:

I can forsee the need for two modes here for those interactive cases
where pages are normally just stacked on top of the previous pages
with a background superimposed at the start and between each page. If
that background is completely transparent, then you should see the
whole stack of previous results right back to the root desktop
(whatever the desktop software would be displaying if the plot GUI was
not superimposed on top), and if the transparency is dropped to say 90
per cent then you will see that stack of previous results gradually
fading away as you display contents from deeper in the stack to make a
really cool-looking effect.  So this possibility of seeing everything
in the stack modified by the transparency of the superimposed
backgrounds in between should be allowed, but there should also be an
interactive mode that starts fresh with each page, i.e., the root
desktop is displayed, then the semitransparent background, then the
plot for the single page.

In sum, this whole field of supporting RGBA background images for each
plot page is an extremely interesting one, but to get the "A" part of
that to work correctly we need to deal with the above issues that show
up even when the background "RGBA image" is a simple one that is
uniformly coloured.

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
__________________________


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

[Plplot-devel] RGBA background images

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

On 2016-02-06 10:09-0000 Phil Rosenberg 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?

Hi Phil:

If you are talking about the goal of having potentially different RGBA
images for each different page's background, then I really like that
long-term goal because you can get some really cool effects that way.
But I am concerned about the speed since it currently takes us an
extremely long time to display even a low-resolution image for example
20. So I encourage you to think about the image display speed issue.
For example, I presume many of our device drivers (e.g., cairo, qt,
and wxwidgets) potentially could display an image using the
(presumably fast) capabilities of the underlying pango/cairo, Qt[45],
and wxwidgets libraries.  So I think one potential way forward is to
implement that "native" image rendering capability in each of those
device drivers (and others as well whose underlying library has the
native capability).  Then plimage lets the driver render the image if
the driver advertises it has the capability, and otherwise falls back
to the extremely slow current method of displaying images.

Meanwhile, I have thought of a closely related topic concerning the
"A" in "RGBA" which I would like to discuss which is how to improve
our current methods of handling uniformly coloured semitransparent
backgrounds. But I will present my thoughts on that topic in a
separate thread so as not to hijack this one.

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...>]

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

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

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

[Plplot-devel] The Copyright file

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

On 2016-01-04 10:14-0800 Alan W. Irwin wrote:

> On 2016-01-04 13:26-0000 Phil Rosenberg wrote:
>
>> Sorry I appear to be filling this conversation with chaff. Can anyone
>> enlighten me as to the (intended) meaning of this statement in our
>> Copyright file
>>
>> Any file that has a explicit copyright notice may be distributed under
>> the terms of both the LGPL and whatever stated conditions accompany the
>> copyright.
>>
>> I have a feeling that this no longer applies and needs removing,
>> perhaps it did apply when (if?) plplot only contained files that
>> plplot contributors had written.
>
> I have no idea why that phrase was included.  I think it is best that
> you remove it.

Hi Phil:

As of commit 6d4e5b192 I removed that phrase and also did some
rewording to clarify that although the vast majority of the files in
PLplot are licensed under the LGPL there are some exceptions.  I
also clarified one set of such exceptions which is
the GPL v2+ status of most of the octave-related files.

As of commit 0641b2c I have added additional exceptions to the
Copyright file that I was aware of for the Chloe.pgm file and many
others.

I would appreciate you reviewing the updated Copyright file to make
sure it doesn't raise any red flags for you.

Finally, I strongly encourage you or anyone else here who is aware of
some PLplot file _with definite licensing_ other than our default LGPL
v2+ to follow up on the above changes by mentioning that exception in
the Copyright file so developers and users always have just one file
they need to consult with regard to copyrights.

One current indefinite licensing issue is the software in lib/nn and
lib/csa. My memory from ~2003 is that Rafael Laboissiere (since
retired from PLplot, Debian, and a lot of other free software projects
but fanatical about free software licensing back then) got agreement
from the original developer of that software to relicense it with our
default LGPL v2+ license. However, my memory may be faulty, there is
no sign of that relicensing in the lib/nn and lib/csa files, and the
last time this came up with Rafael (many years ago now), he could not
remember.  Since 2003 is really a long time ago now, I think probably
the best way to handle this is with benign neglect, i.e, "let sleeping
dogs lie".  :-)

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] Example 19 differences for Tcl [Solved!]

[Arjen M. <Arj...@de...>]

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, January 31, 2016 10:50 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Example 19 differences for Tcl [Solved!]
>
> On 2016-01-11 07:38-0000 Arjen Markus wrote:
>
> > Yes, I will have a look at [these example 19 differences] once the
> > Fortran work is done. Right
> now on my machine such differences are hidden by the fact that Cygwin installation
> is currently missing the shapelib library.
>
>
> However, you are more expert than I am with regard to the Tcl binding so please
> carefully review the current argument list logic for preparing the calls to c_plmap*
> functions to see if any further logic issues exist and to see whether the code can be
> cleaned up any further.  In particular, the current logic cleanup exposed what
> appears to be some inconsistencies in where tcl_interp is set. I frankly don't
> understand the tcl_interp logic so will you please take an especially close look at
> that and fix those inconsistencies? (Or do a further code cleanup to remove the
> tcl_interp logic altogether if it doesn't matter?)
>
> Thanks in advance with your help finalizing this round of changes for tclAPI.c.
>

I had a closer look at the source code and it looked fine. I did realise though that I should at the changes you made, rather than just the resulting code :). So that will a second round.



As for the use of tcl_interp: this is required because the transformation routine does not take an extra argument that would allow us to store the original interpreter in. So the code stores a pointer to the interpreter for later use. This is somewhat unfortunate, as it introduces problems for a multithreaded application, but I see no possibility to do otherwise.



Regards,



Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

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

[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] Example 19 differences for Tcl [Solved!]

[Arjen M. <Arj...@de...>]

Hi Alan,



I will look into this - the issue was indeed swamped by other stuff. But I am glad you found a solution.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, January 31, 2016 10:50 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Example 19 differences for Tcl [Solved!]
>
> On 2016-01-11 07:38-0000 Arjen Markus wrote:
>
> > Yes, I will have a look at [these example 19 differences] once the
> > Fortran work is done. Right
> now on my machine such differences are hidden by the fact that Cygwin installation
> is currently missing the shapelib library.
>
> Hi Arjen:
>
> To resurrect this 20-day old topic, I did not see a commit from you regarding the
> above plan for further action so I assume it got lost deep on your ToDo list.  Since I
> was sorting out some -DPL_DOUBLE=OFF issues with tclAPI.c in any case, I
> decided to fix some obvious logic issues (i.e., if GetEntries didn't find anything
> tacked on to the end of the call, the logic dropped through rather than calling
> c_plmap*) myself. I also did a substantial code cleanup when figuring out the Tcl
> argument lists for plmap* calls.  As a result we now (commit
> 855ac03) have perfect Tcl PostScript differences for all examples (including 19) for
> the -DPL_DOUBLE=ON case!
>
> However, you are more expert than I am with regard to the Tcl binding so please
> carefully review the current argument list logic for preparing the calls to c_plmap*
> functions to see if any further logic issues exist and to see whether the code can be
> cleaned up any further.  In particular, the current logic cleanup exposed what
> appears to be some inconsistencies in where tcl_interp is set. I frankly don't
> understand the tcl_interp logic so will you please take an especially close look at
> that and fix those inconsistencies? (Or do a further code cleanup to remove the
> tcl_interp logic altogether if it doesn't matter?)
>
> Thanks in advance with your help finalizing this round of changes for tclAPI.c.
>
> 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
> __________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

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

[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...>]

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

[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

[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] Example 19 differences for Tcl [Solved!]

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

On 2016-01-11 07:38-0000 Arjen Markus wrote:

> Yes, I will have a look at [these example 19 differences] once the Fortran work is done. Right
now on my machine such differences are hidden by the fact that Cygwin
installation is currently missing the shapelib library.

Hi Arjen:

To resurrect this 20-day old topic, I did not see a commit from you
regarding the above plan for further action so I assume it got lost
deep on your ToDo list.  Since I was sorting out some -DPL_DOUBLE=OFF
issues with tclAPI.c in any case, I decided to fix some obvious logic
issues (i.e., if GetEntries didn't find anything tacked on to the end
of the call, the logic dropped through rather than calling c_plmap*)
myself. I also did a substantial code cleanup when figuring out the
Tcl argument lists for plmap* calls.  As a result we now (commit
855ac03) have perfect Tcl PostScript differences for all examples
(including 19) for the -DPL_DOUBLE=ON case!

However, you are more expert than I am with regard to the Tcl binding
so please carefully review the current argument list logic for
preparing the calls to c_plmap* functions to see if any further logic
issues exist and to see whether the code can be cleaned up any
further.  In particular, the current logic cleanup exposed what
appears to be some inconsistencies in where tcl_interp is set. I
frankly don't understand the tcl_interp logic so will you please take
an especially close look at that and fix those inconsistencies? (Or do
a further code cleanup to remove the tcl_interp logic altogether if it
doesn't matter?)

Thanks in advance with your help finalizing this round of changes
for tclAPI.c.

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
__________________________