Re: [Plplot-devel] Am I using eop() or abusing it?

[Greg J. <gv...@gm...>]

>
> 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.
>
> I compared the two w.r.t. their bitmap creation/storage and it looks the
same.
Anyway, I inserted the eop() call instead into the ->Update() call which was
doing nothing in the win case, so I limited the side-effects to that driver.

In the wingdi case I was getting failures to display in the case where
multiple plots/multiple
windows were created in rapid succession.  The plots appeared when the
window was moved or re-sized,
but I generally got only a single plot of six nominal plots (axes, titles,
and a line).  With the
eop() call inserted, now, that defect goes away! The only side effect is
the rgb+plot test
that needed the plP_bop() removal from rdbuff_bop to work, needs a move or
resize before it shows
 correctly (same side-effect for wingcc).
 Given the hackish nature of the RGB implementation, I can live with that.
[image: Inline image 1]
(I moved and resized the plot on the left to unveil the RGB picture
portion.  The right side
window is as-plotted: 5 sub-plots do not show before re-sizing)

[image: Inline image 3]
 The wingdi driver ran the "testfocus" test without error - all plots were
displayed without
mouse interference. This due to insertion of ->eop() call in ->Update(),
which is called after
each GDL plot routine.  Without the ->eop(), only one plot would show until
the window
was moved.

On Sun, Feb 7, 2016 at 8:22 PM, Jim Dishaw <ji...@di...> wrote:

>
> On Feb 7, 2016, at 1:44 AM, Greg Jung <gv...@gm...> 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
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
>