Re: Plot failure: "Visible pixel grid has a scan line longer than previous scan lines"

[Ethan A M. <me...@uw...>]

On Monday, 29 June 2020 19:51:04 PDT Dima Kogan wrote:
> Alright, I debugged this (rr was invaluable), and I know mostly what's
> going on. The flow is roughly this:
> 
> 1. The data is read here:
> 
>    https://sourceforge.net/p/gnuplot/gnuplot-main/ci/branch-5-4-stable/tree/src/plot3d.c#l1037
> 
>    At the end of the first line, x is 3999.0000000000005, which is just outside the
>    xrange [0:3999]. This isn't unexpected due to the "using" expression
> 
> 2. Later we evaluate the x axis for that point (first row, last col):
> 
>    https://sourceforge.net/p/gnuplot/gnuplot-main/ci/branch-5-4-stable/tree/src/axis.c#l2782
> 
>    3999.0000000000005>3999, so we set this to OUTRANGE
> 
>    In a perfect world we should be looking at the "with image" pixel
>    edges instead of just the center; like we do in step 5 below.
> 
> 3. Later we evaluate the z axis for that same point, but this is already
>    OUTRANGE, so we don't bother to use that point to set axis->min or
>    axis->max
> 
> 4. As a result the view_port_z[] range we set later is narrower than it
>    should be:
> 
>    https://sourceforge.net/p/gnuplot/gnuplot-main/ci/branch-5-4-stable/tree/src/graphics.c#l4822
> 
> 5. And then, further on in in that function, that corner pixel is deemed
>    invisible. So the first row then has only 15 pixels, but the next row
>    has all 16, so we complain
> 
> The logic in step 5 (what we do for !visible pixels) looks suspicious,
> but I want to say the fundamental problem is that step 2 and step 5 have
> different logic for inrange/outrange. The top-right corner of the
> failing plot is OUT in step 2, but IN in step 5.
> 
> Any obvious fixes?

I agree with your analysis.

I have some reservations about whether it ever makes sense to clip
the contents of a plot `with image`, since in the general case of
rotation+translation, clipping will not leave a rectangle and thus the
optimized image-data protocols that pass the image as a single chunk
of data won't work.
The current gnuplot code seems to assume that clipping will cleanly
remove a constant width slice from each edge.  Perhaps one fix is to first
detect that clipping exists, and if so fall back to 'with image pixels' so
that each pixel is considered individually.

Your case, however, triggers uneven clipping not because of rotation
but simply due to round-off error.  Two fixes occur to me.

A) The one implied by your point 2 above: auto-scaling and clipping
should take into account the full width of the pixel.
That can probably be done but I will put that on hold for now.

B) For any given axis (z in this case) the program should never try to
apply both autoscaling and clipping!   I don't know whether this glitch
can happen for other plot styles, but I will look for the most generic
possible place to prevent it.

	Ethan