On 2015-02-20 14:32-0500 Jim Dishaw wrote: > I've gone through the coordinate transformation and where/how it is applied > in the library. The coordinates that are stored in the plot buffer can be > best described as "device virtual pixels" and the definition is not > necessarily consistent across all the devices. I don't think that is a show > stopper and I have argued with myself on the pros/cons of different solutions. > > Solution 1: > Standardize the definition of device virtual pixels (e.g. plplot device > independent coordinate system). Use that coordinate system in the plot > buffer. > > Pros: > - A standard coordinate system being represented to the devices > - Consistency in the device output (direct output to a device vs reading a > plot metafile and rendering to a device) > > Cons: > - An additional coordinate system transformation for some devices > - Coordinate system transformation when the plot buffer is replayed (e.g. > during window resize for some devices) > - Substantial modification to the code, do not recommend this close to release > > Solution 2: > Standardize the definition of device virtual pixels (e.g. plplot device > independent coordinate system). Use device coordinate system in the plot > buffer. > > Pros: > - A standard coordinate system being represented to the devices > - Consistency in the device output (direct output to a device vs reading a > plot metafile and rendering to a device) > > Cons: > - An additional coordinate system transformation for some devices > - Substantial modification to the code, do not recommend this close to release > > Solution 3: > Keep the current implementation of coordinate systems and the plot buffer. > Translate coordinates when reading from plot metafiles or when copying a > stream to a different device stream. > > Pros: > - Less changes to the code > > Cons: > - Round off error during coordinate transformation may result in differences > in the output files > > I think solution #3 is the best choice at this time. In addition, using > solution #3 does not preclude using solutions 1 & 2 at a later date. While I > don't think it is strictly necessary, going to solution #2 in the long term > might simplify the code in the long run.
Hi Jim: I have read and re-read Solutions 1 and 2 and I don't see any difference between how you have presented them. Did you mean to say something else for one of them or am I missing some key word that distinguishes them? Regardless of that issue, I do agree with you it is too late in this release cycle for major _plbuf_ changes since wxwidgets depends on that. So in your further pre-release plbuf commits (if any), please make sure to say bug fix in the commit message so I know it is not some major change. However, plmeta/plrender commits are quite a different story than plbuf commits so I hope you keep the two separate from now on. What I intend to do with plmeta/plrender is note in the release notes that this new version is experimental and will therefore require the user to specifically request it with -DPLD_plmeta=ON. (PLD_plmeta=OFF by default is already implemented for the current build system because the old plmeta/plrender has long been deprecated.) Anyhow, because plmeta/plrender will be disabled by default, this gives you complete freedom to do anything you like with plmeta/plrender (but not plbuf) right up to and through release. Subject to your revision of the explanation of solutions 1 or 2, it does sound like all solutions other than 3 would require major plbuf changes so likely you should follow your instinct and use 3 for now. However, as soon as you are free to make major changes to plbuf (i.e., early in the next release cycle), I hope you quickly move forward with another alternative to 3 because it is important to ultimately have completely identical indirect and direct results with no chance of rounding errors creeping in. 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 __________________________ ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
