Given that getting a color 2D plot to work is so difficult, dropping the
OpenGL from the release would probably break a lot of code that uses it for
color displays.
Why are we only considering fortran-era graphics libraries for graphics?
There have to be a million C++ OO graphics libs out there, and some are
really great (Qt, for instance).
In my experience, getting PDL to play nice with C++ libs is particularly
messy. I generally have to resort to the screwey PDL::CallExt interface, and
then code some funky C++ shared libs (that I need to build outside of the
perl auto-build world).
Maybe we should think about getting PDL and C++ to work together more
effectively, which opens the window for integration with lots of great
graphics packages. I realize that some of the problems getting C++ to work
properly have to do with Perl itself, but perhaps we can at least put some
band-aids over those difficulties and hide them from users and developers.
Here's my short list of things needed for better C++ support in PDL:
1. A quick mechanism for passing C++ objects back and forth, without having
to resort to passing pointers through PDL::PP
2. Get PDL::PP support building modules using a C++ compiler, so PDL::PP
code with C++ functionality can be compiled as easily as C code
3. Build a wrapper C++ object for manipulating PDL vars from within
libraries and PDL::PP code. I've got something like this, which includes
some graphics-on-memory rendering, that can probably be used as a starting
point.
-Judd
----- Original Message -----
From: "Chris Marshall" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Wednesday, June 28, 2006 7:58 AM
Subject: Re: [Perldl] PDL for non-astrophysicists
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
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
