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