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:
>
>  
>
>>I think "graphics.c" is the file I argued should be restructured because 
>>2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
>>ends up being plotted in 2D.)  
>>    
>>
>
>Not everything, strictly.  PM3D stuff doesn't.
>

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 just 
that they are transformed into slightly different way and positioned to 
give the illusion of 3D.  Do you agree with that?  It just seemed like 
better code reuse could have been done there.

>>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.  
>>    
>>
>
>Not necessarily.  I think I can pull it off while only adding
>#ifdef's to graphics.c.  I'll effectively compile the same file
>twice, but select different parts of it to actually be compiled.
>That's a bit hairy, but if patch compatibility is a major concern,
>it can be done.
>

Some strategically placed #ifdefs is not a problem.  The patch program 
usually can figure that kind of thing out with enough offset.  However, 
breaking the file into two chunks would probably cause problems.

>>make work in the time span of making a release.  Maybe it would be best
>>to not rock the 16-bit boat until 4.1. 
>>    
>>
>
>Which will be even bigger, and thus harder to port to 16-bitters. Not to
>mention there's not even a *hint* of a plan when a 4.1 might happen.  
>Averaging over the history of releases since 3.5, that may take 2
>years....
>

Can't argue with that point.

Dan