Thread: image/binary patch updated

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I've updated the image/binary patch (694789) to include Ethan's
drivers for PDF and PNG/JPEG.  (I'm intending that to be the
last update.)

-------

I'm now going to offer some comments about ways I feel Gnuplot
can be improved in terms of code and enhanced in terms of
features.  (Call it a harangue if you like, but I'm not intending this
to be critical.)  No one need respond because the suggestions
are more long term.  Or should I say post 4.0?  Maybe just keep
this post around for future ideas.

1)  Convergence of 2D and 3D plots:  I'm not sure how Gnuplot
developed in terms of 2D and 3D plots.  Perhaps they were
coded separately and then combined.  Perhaps there was a
bifurcation along the way for some reason.  In any case it seems
there is some duplication of code for plotting in 2D and in 3D.

For example, there is "plot_lines()" in "graphics.c" and "plot3d_lines()"
in "graph3d.c".  But are these really that different?  (Perhaps someone
knows better than I do if in fact they are drastically different.)  It
seems to me that "map3d_xy" is the most important detail.  But
couldn't this just be "map_xy()" and if the current mode is PLOT_MODE
as opposed to SPLOT_MODE, say, the map_xy() routine does a simple
unity mapping?

Another example is the image drawing routine I put in
the patch, which  is designed to work for 2D or 3D plots.  If a
Boolean variable indicates that a 3D mapping should be done
then the code will call "map3d_xy()".  [I pause to make a point that
this mapping has to be at the point right where the data is utilized.
The reason is that the data stored in 3d plots is before mapping
because the viewing angle can be changed and the splot redrawn.
The only other way is to map all data and store in a temporary chunk
of memory and pass that in.  But I don't think anyone would think
that is a good idea.]  This image plotting routine is in "graphics.c".

Also in "graphics.c" I see some notes left by Hans such as

> /* FIXME HBB 20020225: this is shared with graph3d.c, so it shouldn't
>  * be in this module */

so I'm guessing he's been faced with trying to adhere to the practice
of code reuse as well.

The point, I believe, is that when it boils down to the actual process
of plotting something, it is always in the 2D viewing plane that this
is done.  Whether this means first mapping from the 3D space or not
is a minor detail, I think.

So a bit contrary to Hans remark in the code, I would contend that
graphics.c is the appropriate spot for all graphic object drawing
routines.  Then the dimension-specific details should go into
"graph3d.c" and a new file "graph2d.c".  Furthermore, consider that
there are two different structures for 2D plots and 3D plots,
"curve_points" and "surface_points".  An argument could be made
for having just one structure.  But even if that shouldn't be the case,
it is the

    int p_count;            /* count of points in points */
    struct coordinate GPHUGE *points;

which are important to the actual graphics drawing routines.  So
my suggestion would be to make all graphics drawing routines
operate on a pointer to the points and number of points or combine them in
their own structure and pass that into the routine.  In fact, if one were to
think about this, I bet if these were packed together and put at the
start of both the "curve_points" and "surface_points" structures the
pointers to these plots could be passed in and there would be no need to
distinguish between the two types of pointers because the important data
would have the same offset in the structures.  The graphics routines would
have a "map_xy()" right before they are used.  (The conditional done
inside the "map_xy()" function to conserve code space.)  So I guess that
means the mode would also need to be packed with those two.  Anyway,
I hope you get my point.

2) Not too far removed from #1, with the image stuff I've added a
a short bit of code to allow a colorbox in 2D plots.  It became clear
to Petr and me that the "3d" associated with colorboxes should be
dropped.  So, it seems that a nice consistent method of adding a colorbox
to a plot, either 2D or 3D, is in order.  Right now they are separate.
However, they should essentially use the same code when laying out
the plot.  Petr had some ideas for enhancing the positioning of the color
box and it is logical to not have to change that in multiple spots.  Also,
the slick routine should place the colorbox at the side of the plot.  Petr
and I have agreed that having the colorbox embedded in the splot 3D
space, so that it moves and changes shape when panning the view, is
a bit lacking.  We contemplated fixing that, but I think it is better 
for the
group to think that one through.

3)  Add the capability of RGB to polygons:  Currently polygons use palette
lookup for generating the fill color.  However, I don't see why there can't
be RGB components just like for images.  I personally can't think right
now what the applications might be, but it doesn't seem too far fetched that
such a thing could find a use.  (I don't know, contouring for landscapes,
color image warping, etc.)  One might argue that would require altering
so many of the terminal drivers so the term->polygon has one extra
variable.  But with xemacs, something like "xemacs *.trm" at the command
line will open all files and a replace function could get the job done in an
hour or two.  Sure it would take some more work to add functionality to
the drivers, but various people could choose their favorite and make the
alterations.

4)  Memory usage for storing data points:  This one probably has the
least chance of being addressed.  The "struct coordinate GPHUGE"
is a bit wasteful of memory if only a few columns of it store data that
is actually used.  It would be nice to have a scheme not so wasteful,
say using a "void" pointer and store just the number of columns actually
used.  However, this is some very "advanced" programming, especially
when there is a group of developers.  Many would make the "worst
case scenario" argument for not doing this.  So, ey, just an idea and
I wonder how many feel this is important.

5)  There are some routines in "show" and "set" that list the options
for plot styles, etc.  The strings for these always have to be updated
and some times may become out of date.  Would a little routine be
worthwhile to simple go to the table and pull out the style strings and
print them?  The routine would have to know when there is no more
room on an 80 character line to show the next string and first enter a
carriage return.

6)  How about a simple "help search <text>" routine that searches through
all the gnuplot.doc strings and dumps out the headings of all subtopics that
contain <text>?

Dan

Thread: image/binary patch updated

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta