> On Feb 6, 2016, at 5:09 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> 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; plplot-devel@lists.sourceforge.net
> 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.rosenb...@gmail.com>
>> 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...@beluga.phys.uvic.ca> 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>
------------------------------------------------------------------------------
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
