I am working on #3 but took a detour when I had to shift to my laptop due to travel. I couldn't get a successful build on my laptop, so I was working on Mac OS X build problems.
I'm back at my primary development machine, so I will finish up on #3. I'm very close. The plots render but they are scaled a bit too large. > On Feb 28, 2015, at 4:28 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2015-02-20 13:13-0800 Alan W. Irwin wrote: >> >>> 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. > > Hi Jim: > > How is your implementation of #3 coming along? > > I am strongly interested because it sounds like that will provide > capabilities for your rewritten plmeta/plrender that should produce > identical results (except for plbuf bugs and the occasional rounding > error that propagates to the heavily rounded PostScript or SVG > results) for the direct result versus the indirect result done via > plmeta/plrender for all our different examples. And, of course, such > comparisons would be a tremendous help in finding plbuf bugs and > fixing them before the release. > > I have stated your rewrite of plmeta/plender based on plbuf was > urgently needed for plbuf testing some time ago, but I suspect you > have forgotten that remark which is why I am repeating that message > again here. :-) Ideally, it would be good to have in hand on Monday > your patch series consisting of your rewrite of plmeta/plrender based > on scenario 3 above since (as stated elsewhere) that day is when we are > going to review our plans for wxwidgets/plbuf debugging for the rest > of the current release cycle. > > Note, just to simplify my release manager's life, I probably will wait > until early in the next release cycle to push your rewrite of > plmeta/plrender. However, that does not preclude us from using that > work now (transmitted to us as a patch series) as an important test > tool for plbuf. > > 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
