The eop call is required because there is some code in bop that needs to be called, but if bop is called before eop then that function just returns.
I am sure that you will find the same thing for the Windows driver too. To be honest I was recently thinking that the buffer is fast approaching a rather uncomfortable midway point between either representing only graphics operation or representing pllot commands. This comes from the fact that drivers also sit in this uncomfortable midway point. A good example is the clear operation. The clear operation should clear the subpage, but that requires the driver to know the subpage geometry so instead of the driver receiving the graphics operation of "fill this rectangle with the background colour) it is left for the drivers to fish that geometry from the stream. I can understand why this is done because some drivers may be able to actually clear regions rather than just draw a box. For now I think we just have to live with it and work the buffer as best we can, in this uncomfortable zone. But in the long term I would suggest that the drivers should not be given access to the stream. This will put them solidly in the graphics device region and make the buffer way simpler. But at the same time we have plenty of other stuff to do so I don't think this is anything like a priority at the moment. Phil On 7 June 2015 at 05:25, Jim Dishaw <j...@dishaw.org> wrote: > While working on my old Windows GDI based driver (see attached patches), I > stumbled across the problem that prompted Phil to add plP_eop() in > plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on > problems with -np when running automated testing. > > In plbuf.c, the EOP is never inserted into the plot buffer while the plot is > being generated. The obvious issue to having an EOP in the plot buffer is > that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI > driver that could cause problems (i.e. the WaitForPage() in the xwin driver > would be called multiple times). While working on wxwidgets, Phil added a > call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers > the EOP handler and results in the need for a keypress. I thought > eliminating the call to plP_eop() would be the simple fix (it does fix the > bug) but having the EOP is handy when redrawing the plot. > > I looked at the possibility of keeping the EOP in the plot buffer, but there > is all sorts of messy code on trying to “do the right thing” that I think > might cause more problems. In the ideal world, I like the symmetry of having > both a BOP and EOP in the plot buffer. However, to support that correctly in > the GUI drivers might be tricky. Instead, I think the best solution is to > eliminate the plP_eop() call that was added into plRemakePlot. That will fix > the issue that Andrew raised. The downside is that Phil might need to make > some changes to wxwidgets. It took some effort to get the new windows GDI > driver working without the plP_eop() call, but it does work. I can make a > fix for plbuf.c that removes the plP_eop(). > > @Aaron & Alan (and others who might be interested) > I have attached two sets of patches. One fixes some build problems I was > having with MSVC and the second implements the new windows GDI driver (which > is mostly done). I need to add some features that I had in my old driver > (coordinate point picking, optional tab interface, saving plots into files, > optional menu bar). Should I add Freetype back in? > > Once I finish with wingdi, I will implement the Direct2D version. > > > @Alan > > I was not able to uncrustify. I have not had time to set it up on my Windows > machine. Sorry. > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
