Re: 16-bit versions of gnuplot doomed?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Wed, 25 Feb 2004, Daniel J Sebald wrote:
>
>[PM3D stuff doesn't go through the 2D parts of gnuplot]
>
>  
>
>>In some sense it does.  I mean, it may not be set up that way, and that 
>>is why I say the two are diverging.  When it boils down to it, 3D is 
>>still just drawing lines, filled polygons, colorbox key, etc. 
>>    
>>
>
>It's exactly the filled polygons that don't really use any 2D stuff.
>
>The rest of the plot (largely) doesn't care whether a given dataset is
>output as pm3d, lines or points, but the actual surface plotting, where
>the real work is, does.  Note that the core data structure you pass
>to term->filled_polygon takes an at least optionally 3D data point for
>input: struct gpiPoint.
>
>  
>
>>give the illusion of 3D.  Do you agree with that?  
>>    
>>
>
>As long as we don't add an actual 3D terminal driver (OpenGL, VRML
>or whatever), yes.  But that's not something we have to worry about now.
>
>  
>
>>>>It should be just the core routines for graphics and then maybe a
>>>>"graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
>>>>right now it will undoubtedly mess up some of the patches currently on
>>>>SF.  
>>>>        
>>>>
>
>Well, the "core routines" are actually in term.c and the drivers, not in
>graphics.c.  The current graphics.c is esentially just that graph2D.c
>you're talking of.  It contains exactly those things that are specific to
>2D plotting: the implementations of 'with <style>' for 2D, and the 2D
>graph area positioning stuff, particularly the rather monstrous function
>boundary().
>
>A more natural split of graphics.c could therefore be along those lines.
>I.e. it might make sense to split out boundary() and its helpers into a
>new module layout2d.c.
>

Well, certainly that.  I think there was a discussion about better using 
the visual space in 3D plots.  Plus I think there is use for the 
colorbox key in 2D.  So here are some similar features that are handled 
differently depending upon the type of layout.  So there is that aspect.

What I was thinking of has to do with the image stuff I did.  However, 
now that I look more closely, it could be that the image case is 
slightly different from the other lines/points type of drawings.  What 
I'm seeing in graph3d.c are a number of routines (e.g., plot3d_lines) 
that aren't for plotting just one line, but for plotting a series of 
lines.  And plotting a line is fairly fundamental that it is easy to 
simply call a vector routine from the 3D routines.  However, in the case 
of drawing an image, which could be in 3D or 2D I certainly didn't want 
to have one for 2D and one for 3D.  So they are combined into one where 
there is a test inside of the image routine as to whether a 3D 
projection should be done.  Let's hold off this discussion.  There are 
too many issues surrounding this.

Dan