On Saturday, January 10, 2015 at 15:54:23 (-0800) Alan W. Irwin writes: > I assume for the purposes of the further discussion that you meant > "internal" physical device coordinates but please confirm that (or > take the rest of what I say with a grain of salt if that assumption is > incorrect).
That's correct. > The problem with using shorts to represent internal physical > coordinates is those 16-bits are not really enough. There are > problems with zoom (as mentioned by you above). Also, there are > problems for the unzoomed case. For example, we had to fight for > years to desensitize our standard examples to floating point rounding > issues. The problem was we needed to avoid certain magic numbers > where our input PLFLT world coordinates or normalized device > coordinates (say for any labels or tick marks) would transform to a > position almost exactly between two integers in internal physical > coordinates so that a very slight floating-point rounding error in > calculated positions would propagate to a substantial visible change > in the resulting plot. Because of these known floating-point rounding > sensitivity issues, I am also convinced (although I cannot tell for > sure because I am used to the current look of PLplot results) that our > plots would likely look much smoother if more than 16-bits was used to > represent internal physical coordinates. > > When this internal physical coordinates representation issue was first > brought up on the list more than a decade ago as a result of > Geoffrey's bad results with zooming, we discussed a number of options. > At the time I advocated simply using PLFLT (normally 64-bit floating > point) for the type used for internal physical coordinates. Because > memory and disk space are cheap now, I see absolutely no fundamental > issues with this solution except for the one important issue of plmeta > bandwidth where plmeta results that are written in internal physical > coordinates would automatically be a factor of 4 larger than the > present case where internal physical coordinates are represented as > shorts. > > I think the solution to this dilemma is to typedef a PLINTERNAL type > which normally is the same as PLFLT, but for critical plmeta bandwidth > cases the user still has the option to build and use a PLplot version > that typedefs PLINTERNAL as short. In association with the zoom issues observed about a decade ago, I had work in progress to up the device space from 16 bits to 32 bits. This resulted in a huge improvement in resolution of course, but some surprising side effects, such as redraws becoming noticeably slower. I never got around to figuring out if this was avoidable -- I was pumping 2x as much data through the plot buffer code so maybe not. And in that case maybe it would've been just fine. The real sticking point with the 16->32 bit change (not to mention floating point) was the way dashed line draws are done. At least at that time, it reeked of suck. The dash segment draw required an iteration over each addressable point to find the demarcation point. So it got really slow, and any fix might require a rewrite of the dashed line logic. Aside: we ended up going with a different approach -- handling redraws from the client side, which worked out great. But unfortunately I had to abandon the plplot-side effort due to lack of time. -- Maurice LeBrun ------------------------------------------------------------------------------ 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
