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

Reply via email to