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>