If TriD/OpenGL is problematic (i.e. no support and broken) then a good case could be made for moving it out of the PDL release tree. My recent progress to get PDL (including PDL::Graphics::TriD::OpenGL) working under cygwin leads to some questions and comments:
1. If OpenGL is removed, what will be the baseline tool for 3D PDL plotting and *2D full color image* plots? OpenGL has the advantage of widespread availability (windows, unix, and other platforms). PGPlot cannot plot 24bit color image data. (I don't know if PLPlot can do so). 2. I don't know how well Karma does in this regard since it has not yet been ported to cygwin where I could evaluate it. 3. For replacements, maybe we could use vtk or some other graphics toolkit. What are other PDL users using for 3D graphics or are does no one use 3D? 4. TriD::OpenGL could definitely use a bit of clean-up although that has already been accomplished to some extent by CED. That clean up was enough to keep the cygwin build from crashing outright on WITH_3D set and allowed my to fix the compile options to get the TriD/OpenGL build to completely. I recommend a clean-up and stablization for TriD and OpenGL this release go-around followed by removal/replacement/upgrade decision in the next release cycle. For Example: A look at the current implementation suggests that moving from raw X11 to GLUT for the window controls would give better portability, simpler event handling, and multiple 3D plot windows. 5. Testing definitely needs to be improved for the clean PDL builds to help first-time and prospective users get the best start (& a good 1st impression). 6. Improved documentation for beginners to start and for experts to refer would help. I hope the Wiki idea will help with this. This coming release should include a respin of the "PDL Book" since the current version seems to be not too far from something that could go out with 2.5 or whatever. --Chris > The opengl and TriD code has been without explicit > support for a while and I suggest separating it out of > the main PDL release tree. As seen below it does give > us a bad rep and let us be honest: this part of the > dist is effectively orphaned. > > Christian > > Bill Coffman wrote: >> >> Later discoveries that made (and continue to make) >> me leery. >> 1. The opengl code is a mess. opengl.pd contains loops >> labeled hack, hack2 and hack3 -- clearly (hopefully) >> the author did not intend this to be released. >> 2. The cvs code is pretty bad. The new eigens function >> (from ssl -- probably not such a great acronym for >> "small scientific library") was apparently never tested >> on a matrix larger than 2x2. Opengl didn't even >> compile. Since I only looked at a small portion of >> PDL, I must assume that there is a lot more problems >> where that came from.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
