Re: DPU-414 terminal

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

On Thursday 22 May 2008 05:38, Thomas Sefzick wrote:
> 
> > Can you work out where/why the loop happens?
> 
> well...
> the loop is not endless, but stepping
> from  4294967266, 135
> to 350,  135
> stepsize 1
> takes a loooong time...
> 
> this '4294967266' was meant as '-30' in 'term.c' procedure 'test_term'.
> it was produced by
> (*t->move) (xmax_t / 2 - t->h_char * 10, ymax_t / 2 + t->v_char / 2);

As I said in the comment attached to your patch, I'm afraid the
underlying problem is a design flaw in gnuplot.  It tracks terminal
coordinates as unsigned values, which makes proper clipping virtually
impossible.  Unfortunately, changing the coordinates to signed values
would touch essentially every bit of code in the program.

The bitmap terminals are pretty ancient code at this point.  Other than
special devices like your DPU gadget, there isn't any incentive to 
use or modernize them.  The PBM driver was at one point a reasonable
output path, but for years now PNG has been better for any purpose I
can think of.  So there is not much gain to be had from reworking the
code in bitmap.c. But if you are so inclined - go for it.  As a minimal
patch, one might just modify b_vector to ignore any call for which
the coordinates are out of range.  That would not be proper clipping,
but at least it would prevent memory access violations when flipping
bits in the bitmap array.

On the other hand, it's possible that by now we have wrapped almost
all of the terminal calls originating from the core code in calls to 
draw_clip_line() and clip_move(), clip_point(), and so on.  It might
well be worth the effort to find and fix the few remaining cases.

	Ethan

 
> xmax is 320  (because of 'dpu414 draft')
> t->h_char is 19  (because of 'dpu414 large')
> and 160-190 is -30, but it's interpreted as 'unsigned int' by 'b_move', so
> it's 4294967266.
> 
> and then b_vector(350, 135) is called which then calls b_line(4294967266,
> 135, 350, 135)
> which takes a long time to step from 4294967266, 135 to 350, 135
> 
> how to repair this?
> check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and
> '*t->vector') that all arguments positive?
> everywhere, where 'b_move' and 'b_vector' are called?
> that's a lot of work...
> but i don't see another solution
> 
> thomas
-- 
Ethan A Merritt