2D plotting with OpenGL is as easy as setting z to 0. The hard part is the plotting routine, not getting the plot on the display. Much of the work would be labels and axes...
I don't think the cmake build system is bad so much as unfamiliar (at least to me). It has the advantage of only depending on a C compiler and not a shell (many flavors) and make (many flavors) and all requiring special handling on the end cases. What is lacking is someone using the various platforms and giving feedback on problems until the various issues can be resolved. It seems sort of like what PDL + TriD was like before the POGL work.... :-) In fact PDL configuration would be much simpler if we moved from ExtUtils::MakeMaker to Module::Build or some such. That would change the X shell + Y make requirement and configuration steps to a perl based one. --Chris On the PLplot build system, On 2/8/2010 1:43 AM, David Mertens wrote: > Chris - > > I've thought a bit about what you wrote about PLplot. I agree that > the 'right' solution to cross-platform 2d plotting is an interface > between something and OpenGL. I advocate PLplot, but could be > convinced that PGPLOT is the way forward if somebody can figure out > the interface and licensing (or is that just FUD?). I just figured > that removing the z-axis from TriD would be a quick hack that would > spur us on to finally interfacing PLplot with OpenGL. As it is, > OpenGL already renders lines for us, albeit in three dimensions, so we > should be able to use that rendering and force the viewing orientation > to be 'straight on,' right? > > The problem with PLplot at the moment is that it's build process is so > clumsy. Please understand that I do not mean any disrespect to the > PLplot developers: they simply cannot depend on a good shell scripting > language. Cygwin? MinGW? VC++? Each of these have slightly > different build processes, but batch files aren't powerful enough to > detect the differences and act accordingly. The PLplot people do not > release pre-compiled versions of their libraries, either, which makes > sense given the large number of ways you can configure the library. > The only practical approach is the one they took: to write > instructions explaining how to install PLplot by hand. > > However, WE CAN expect Perl to be available, and we can make a number > of assumptions about what we want in our builds of PLplot. Therefore, > I am considering writing some sort of Alien package for PLplot. > Hopefully it will be as simple as wrapping the build of PLplot in an > ExtUtils::MakeMaker script (or Module::Build script, but I'd need to > get a lot of help for that). A first cut would be a plain-old perl > script that attempts to detect the build system and either builds the > makefile or invokes the correct build commands for PLplot. Among > other things, this would eliminate the need for cmake, which is even > worse in my view than requiring a fortran compiler because the latter > would at least be useful for other PDL modules. If I could get some > sort of script that installs it on any 'reasonable machine' running > Perl, we might be able to seriously consider using PLplot for > cross-platform plotting. > > Wish me luck. I'd love to pour time into this but I'm very busy. I'm > sure that describes us all. :-) > > David _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
