Re: Clipping code - history?

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

Ethan A Merritt wrote:
> In gadgets.c we have the very nice clipping routines:
>  clip_line() draw_clip_line()
> 
> In graphics.c we have a separate collection of very specialized
> but also rather complicated routines:
>   edge_intersect() two_edge_intersect()
>   edge_intersect_steps() edge_intersect_fsteps()
>   two_edge_intersect_steps() two_edge_intersect_fsteps() 
> 
> Is this a code duplication due to historical artifact?

Not really.  The /.*edge_intersect.*/ routines clip in ways specific to 
individual plot styles, governed at least partly by the 
INRANGE/OUTRANGE/UNDEFINED information from function/data parsing.  At 
least the UNDEFINED flag is not available in any other way, so it has
to be like that.  And checking INRANGE / OUTRANGE flags is faster than 
calling a generic clipper every iteration of a (possibly loong) list of 
data points.

These are not really just clipping routines for individual edges; 
they're parts of the plot routines for outputting plots in a correctly 
clipped way.   That's why steps and fsteps get their own clippers, and 
why these clippers work in data coordinates (floating point), not in 
terminal integers.

> At first glance all of the 100-200 line *_edge_intersect_* routines
> appear to do essentially the same thing as a simple series of calls
> to clip_line(). 

Yes.  But there are differences, and IIRC, some of those are somewhat 
easy to miss on casual reading.   BTDT years ago.

> Many code sections in graphics.c and graph3d.c test and sort line
> segments 

I don't recall any sorting being involved.

 > by the inrange/outrange property of their endpoints,
> and then call these single-purpose *_edge_intersect_* routines to
> perform clipping. 

... and they do that *only* in those case where it's actually needed.
That's an important aspect of how that's being done.

 > I am wondering if these sections can be simplified
> dramatically by instead drawing all of the individual segments via
> draw_clip_line().

I don't think so.  Doing this in data space, on floats, has some 
advantages that would be lost if you did this in terminal coordinates.