From: Jim D. <ji...@di...> - 2015-06-07 18:34:13
|
> On Jun 7, 2015, at 9:53 AM, Phil Rosenberg <p.d...@gm...> 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 <ji...@di...> 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 >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> |