|
From: Daniel J S. <dan...@ie...> - 2005-08-18 19:42:38
|
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. > > 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. I wouldn't rule out any such oversight on my part. There could be half a pixel extending past the "wrap-around" border in some circumstances. Then again, should it be the core's responsibility to deal with boundary checks if ultimately these terminal parameters come from the terminal driver? If yes, then where should the boundary checks be placed? As part of map_x() and map_y()? That would seem to be the logical place for good code reuse. Dan |