Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> The image drawing routine does not use INRANGE.  Originally I intended 
>> that.  There is an in range test in a way, however.
>>
>> Here is the issue.  When we speak of a *point* being in range, that is 
>> one thing.  But consider that the pixel of an image has a 
>> non-negligible width.  So, there can be pixels for which its centers 
>> are just outside the viewable border.  
> 
> 
> Well, nobody ever promised doing proper clipping would be easy.  It 
> rather certainly is not --- as you can see by looking at the existing 
> code.  You didn't believe plot_lines() is a 50-line function just for 
> fun, did you?

To quote the Monkees, I'm a believer.

> 
> The fact that it's hard is all the more reason to do it in the core, 
> where we only have to get it right once, instead of re-inventing this 
> for every terminal driver.

I think it can't, but let's continue to hash this out...  Image data sent to a plotting device, like a PostScript interpretter, is a rectangular matrix--essentially a uniform sampling of intensity (light, field strength, temperature, etc.).  There is no way to include in that data individual information about a pixel, say, pixel 25 should be only 0.67 the size of the uniform sampling interval.  Rather, I think the only control is to specify an overall visible range for the image.  The driver can then stop drawing the pixel once outside the viewable range.  This scenario arises when the viewer's resolution is higher than the image data itself, i.e., when an image pixel actually occupies 30 screen pixels, say, in X11.

Dan