From: Jim D. <ji...@di...> - 2016-02-08 20:22:05
|
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 <gv...@gm...> 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 <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 > |