> On Feb 7, 2016, at 1:44 AM, Greg Jung <gvj...@gmail.com> wrote:
>
> 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
> <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.
>
What is happening is that plplot is generating the bitmap used for redraws
before your GDL additions to the window. The second EOP call is forcing the
creation of a new bitmap, which has the GDL additions.
The new wingdi has a much more robust handling of redraws and resizes,
primarily because it closely follows the Windows API documentation. I remember
that the wingcc driver was not very smart about creating the bitmap and I had
to crack open the documentation on how to do it the “right” (where “right” is
relative to the Windows API and not PLplot’s state). What I think is happening
in the wingdi driver is that the additional draws are triggering a new bitmap
independent of the EOP call.
> 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.
A lot of the EOP handling happens outside of the rdbuf_eop(), which is why that
function is a no-op.
>
> 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?
For an interactive driver like wingcc and xwin, I think the primary problem is
that you would lose everything after the first EOP when the buffer is replayed.
That can happen in the wingcc driver in a WM_PAINT message if plplot is
waiting for input and there is not a valid bitmap for a redraw. You may be
fortunate that the second EOP is creating a valid bitmap, thus avoiding the
buffer playback.
> Thanks,
> Greg
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
