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
