Thanks for the update. I will see if I can fix it. It appears that the message
handling loop is not handling some of the messages because it is in the wrong
state. I haven't tested the case with rapid window creation.
On Feb 8, 2016, at 3:11 PM, Greg Jung <gvj...@gmail.com> wrote:
>> 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.png>
> (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.png>
> 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 <j...@dishaw.org> wrote:
>>
>>> 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
>>> 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
