gnuplot-beta

Re: 16-bit versions of gnuplot doomed?

[Hans-Bernhard B. <br...@ph...>]

On Wed, 25 Feb 2004, Ethan Merritt wrote:

> But is it not sufficient to support these machines under linux?

No.  Some of the boxes we're talking about here couldn't run Linux even if
their operators' lives depended on it.  An actual need for a 16-bit DOS
version means real DOS on a 286-class or even smaller machine.  An actual
IBM PC/AT or PS/2 model 30, roughly 10 years old or older. Such boxes
won't even run the 32-bit DOS binary, like the DJGPP one which I'll
certainly prepare and package a release of.

A need for 16-bit Windows versions can arise even on a 486 box, _if_ it's
still running Win3.x, without the "Win32s" add-on installed.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: 16-bit versions of gnuplot doomed?

[Hans-Bernhard B. <br...@ph...>]

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.

> 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.

> 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....


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

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

Re: 16-bit versions of gnuplot doomed?

[Hans-Bernhard B. <br...@ph...>]

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.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

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