This mirrors my recent experience with gnuplot exactly. Using this as a basis for plotting in PDL is going to be a maintenance issue.
-Judd ____________________________ Judd Taylor Software Engineer Orbital Systems, Ltd. 3807 Carbon Rd. Irving, TX 75038-3415 [email protected] (972) 915-3669 x127 ________________________________________ From: Craig DeForest [[email protected]] Sent: Friday, July 13, 2012 2:17 PM To: Dmitry Karasik Cc: chm; [email protected] Subject: Re: [Perldl] common denominator graphics for PDL I'm behind Chris's idea too, if it becomes a standard everyone can point to. I overhauled Dima's nice gnuplot module into something sufficiently top-heavy to hide most of the weirdness that is gnuplot itself. I owe Dima an apology for breaking some of the functionality that he put in there, but am working on unbreaking it now. I'll continue using gnuplot for publication quality stuff for some time, but I don't think that gnuplot itself is the ideal go-to-first solution for graphics, for a couple of reasons: (1) gnuplot is baroque and top-heavy. It makes simple things very simple, and moderately difficult things insanely difficult. (2) gnuplot is slow compared to (say) vanilla pgplot, so that a lot of things like on-the-fly rendered animations are difficult or impossible. (3) gnuplot is fragile - it is a complicated beast, and despite Dima's careful interface work it is possible to hose up the complicated state between PDL and Gnuplot itself. It is telling that every plot has a race condition, since it is possible to get into a state where gnuplot waits forever for input, and it's not in principle possible to know whether gnuplot is waiting or just working hard. (4) gnuplot's syntax is insanely complex. I have attempted to hide most of that complexity from the user, with a modicum of success -- but there are many, many exceptions and special cases. One has to choose between very smart Perl code that attempts to regularize the syntax, vs. very smart users who refer to the manual constantly. The reality is that even very smart Perl code won't be able to track all the corner cases and irregularity and "this-is-how-you-do-its", so a *lot* of headspace is required to be able to produce good plots. (5) gnuplot is not easily adaptible to an imperative model of drawing - the interface is keyed to an atomic "plot" operation. Typical operations for me to develop complicated plots (one such plot is attached) would involve multiple plotting commands in PGPLOT or Plplot; doing the same sort of thing in Gnuplot involves assembling a giant data structure of plot descriptors, all of which get shipped off on one giant parameter list (the attached plot includes over 50 overlain plot lines, all executed in a single call to Gnuplot's "plot" command). (6) gnuplot interactivity is a bit baroque and hard to use reliably. I seem to have broken interactivity in recent versions of my git tree, but even with Dima's prettier original code it was very hard to get events in and out of the graphics. Those things said, Gnuplot *does* produce beautiful output when prodded appropriately, is in active development and well supported, and is reasonably device-independent for the major pixel- and vector- interface formats. In brief: I think gnuplot (and PDL::Graphics::Gnuplot) has good potential as a publication quality plot back-end, particularly for people who are used to gnuplot from elsewhere - but appears unsuitable as a main general purpose graphics backend. Cheers, Craig > > On Fri, Jul 13, 2012 at 11:37:55AM -0400, chm wrote: >> David and all- >> >> I think it is time to resolve the PDL graphics >> problem, "this missing link" by getting a basic, >> standard capability for PDL. >> >> I propose the standard display graphics for >> PDL be based on the Prima graphics toolkit >> by Karasik et. al. and the current code for >> PDL::Graphics::Prima by David Mertens. >> >> A start would be to review the common usage >> of PGPLOT, PLplot, and Gnuplot to come up with >> a Top 10 of use cases to implement. They >> should be *very* simple to use and have smart >> defaults so the common case versions of the >> Top 10 can be done in 1-line or less. :-) >> >> Motivation/justification: >> >> * More beginning PDL users thanks to the >> PDL Book and the increasing buildability >> and usability of PDL on all platforms. >> It makes it more glaring that we don't >> have a good, common, default graphics. >> >> * Alien::XXX development has not matured >> enough to allow easy use of PLplot and >> PGPLOT and it is arguable that we want >> the base display graphics to be readily >> available from perl/CPAN which Prima >> is. >> >> * The use of Prima will provide an easy >> to use, default GUI environment for more >> sophisticated and user friendly PDL >> applications. >> >> * If we could get that base graphics up >> and running for the next point release >> (which will include the new NiceSlice >> filter engine and 64bit indexing) we >> would have a compelling platform for >> future growth. >> >> One downside, I am not prepared to push >> this effort through as I'm pretty busy >> working to make time for the final 64bit >> index development and the new NiceSlice >> engine support (the missing piece is the >> ability to use NiceSlice in an eval such >> as the pdl2 or perldl shells. >> >> I'm hoping that David might be willing >> to spearhead this development and maybe >> hold off on the Core diving for a bit. >> >> At any rate, I think the time is right >> for this to happen and the sooner the >> better. >> >> Thoughts, comments, "volunteers"? >> >> --Chris > > -- > Sincerely, > > Dmitry Karasik > > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
