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