Re: Bug in image code ?

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

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?

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.

 > They'd be classified as OUTRANGE, but really a
> portion of the pixel would be visible.  Agreed?  

If you refer to pixels only by their center (and a globally fixed size), 
then yes, that can be OUTRANGE without the pixel itself being completely 
obscured.   But exactly because it may be quite large, it's dangerous to 
assume you can just plot it and expect the terminal driver to resolve 
this peacefully.  The bug we're discussing demonstrates quite nicely 
just how wrong that can go.

> But, unlike pm3d, there is no easy way for the core to create portions 
> of a pixel because of the nature of image data.  

Then maybe that nature of image data has to be re-thought.

> This is why I said a portion of a pixel might be extending off the 
> viewable boundary.  

That may still be fine.  What's definitely not fine is if the coordinate 
of the pixel that you output to the driver is not just outside the graph 
box, but actually off the page.