On 2015-03-05 14:44-0500 Jim Dishaw wrote: > > On Mar 5, 2015, at 5:45 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > >> I sort of agree. Sounds like a maintenance nightmare, plus, again, I thought >> that was the buffer's role - sit after major processing (e.g. After contour >> generation) but before device dependence, collecting commands which can be >> transferred to any device for repotting? > > The buffer essentially sits right before the call to the driver. The > information stored in the buffer are in the device specific coordinate > system. The original purpose of the buffer was to redraw the window on a > resize event. The plot buffer can be brought up the hierarchy, but the > tradeoff is reduced performance on window redraws. Plus, as Maurice points > out, the current code architecture is not designed for a mid-level interface. > > Consider the case of a dashed grid. The dash is specified as lengths in mm, > thus there will be a different of number of dashes for different physical > sizes. For example, in x01c I count ~2 horizontal dashes between vertical > ticks on the psc device, ~3 on the xwin device, ~2 on qtwidget, and ~2 on > cairo. When resizing the GUI windows, the number of dashes remains > unchanged, which violates the specified dash lengths. > > While working on the code, my thinking has iterated over different solutions > as gained a better understanding of what is happening in the guts. There are > two basic directions that we can go with plbuf/plmeta. > > 1) Keep the current structure and live with the differences in rendering > > Pro: Less change to the code, better performance on redraws > Con: Resized windows or rerendered plots might not be correct in appearance. > > 2) Move plbuf up in the architecture and make plmeta a very smart driver. > > Pro: Plots would be rendered correctly (e.g. dash length) on redraws or when > output on different devices from a metafile. > Con: Redraw performance will be a bit less (probably not noticeable on most > machines), more change to the code
> What I mean by a "very smart" driver is that it would be able to do all graphic operations natively (e.g. dashed lines, pattern fills). "graphic operations" sounds like actually displaying something when I am sure you didn't mean at all so I am lost as to what you really meant here. So could you expand/clarify? > I think the second option is the right way to go and it is closest to what was originally discussed when this effort started. Hi Jim: I don't feel competent to comment on what the final decision is going to from the coding architecture point of view so I will let you, Phil, and Maurice hash it out between you. However I do have some (mostly obvious) points to make otherwise. 1. You are in the best position to make this decision, and I don't want to over-advocate my "solution" too much (which I assume would be part of alternative (1)) since it is obviously just a hack which might work, but which further complicates our code. 2. Alternative (2) is obvious post-release material. 3. If your final decision is to forget about alternative (1) even in the short term, then that is fine with me although that means plmeta/plrender will not be ready enough before the release to provide a good test platform for plbuf. That in turn means we have to be careful to thoroughly test all plbuf changes from now until release by (a) resizing xwin results, (b) looking at results for all examples, and (c) especially checking wxwidgets results. We have already been hit at least once on this matter with a plbuf change (since fixed) that clobbered character sizes in certain rare situations (e.g., character sizes in example 2.02). That means for every further plbuf change in this release cycle we unfortunately are going to have to look at every page of every example to make sure no other problems arise from the plbuf change. I think the lack of zoom for -dev tk and the plframe GUI might be an example of a similar issue, and I plan to follow up by checking with git bisect to see when this regression in behaviour occurred. > @Alan: I will update the documentation as requested. Thanks. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
