Re: Bug in image code ?

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 11:06 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > Yes. It's really a nightmare. Although you raise a possible 
> > issue below, my inclination is that we should never be using
> > unsigned coordinates.  Wrapping around to a large positive number
> > is far worse than going negative.
> 
> Not really.  It's the same problem in a different dress.  Terminal
> coordinates are really only valid in some interval.  That interval 
> always has one endpoint at zero, by design, so it makes sense for the 
> coordinates to be unsigned.  It being unsigned even helps generate 
> faster code: a single test for (x < term->xmax) will detect points that 
> are off to the right or the left.

Detect, yes.  But it does not allow you to clip the line segment.
For that you need the "true" negative coordinate so that you
can interpolate the intersections with the plot borders.

> Any case of a coordinate outside that range being passed to the driver 
> is a bug in the core: it's a clear sign that somebody forgot to do 
> proper clipping.  

We are somewhat talking at cross-purposes.
I agree that the core routines should clip before sending to the
drivers. Fine.  The problem is that the core routines *themselves*
use unsigned integers, which they should not.  And once the arithmetic
has started using unsigned ints, clipping becomes much, much harder.

> >>And try to remember that we have at least some drivers 
> >>where
> >>
> >>	INT_MAX < term->xmax < UINT_MAX. 
> > Are you sure?  Which ones?
> 
> All the 16-bit platforms easily have this potential, 32-bit ones can be 
> driven there.

But only if the terminal claims to have > 32768 pixels.
Is that in fact the case?

> Win16 always is close to behaving like that by default during 
> copy-to-clipboard (24000x18000 pixels).  Many others, including 
> postscript, can be made to, if you only 'set size' high enough before 
> 'set term' or use the driver's own 'size' option.

'set size' is itself highly problematic.
I'll make the provocative assertion that size > 1.0 should not
be allowed.  Or allowed only with the caveat "if you set size > 1.0
then do not complain if your terminal overflows or segfaults".
 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195