> On Jun 7, 2015, at 9:53 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > 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. >
The extra plP_eop() causes problems on the new wingdi driver that I wrote. Nothing insurmountable, but I will dig around for a solution that also fixes the multiple keypress bug. > 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. > I agree. In the new wingdi I tried to minimize the use of the stream. > 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
