Re: Short vectors are not plotted

[Ethan A M. <EAM...@gm...>]

On Saturday, 04 November 2017 21:43:09 Dima Kogan wrote:
> Ethan Merritt <eam...@gm...> writes:
> 
> > Here's a start. I'll probably commit these changes to CVS when the
> > current turmoil settles. After applying this patch there is only one
> > call site for term->arrow() in the code base, in draw_clip_arrow().
> > Could be I'm missing some complication, but it looks to me that any
> > changes needed for your heads-only implementation can be limited to
> > this one routine.
> 
> Here's a new patch series. These assume your use_draw_clip_arrow.patch
> is applied. Again, please apply with 'git am', or let me know what is
> unsatisfactory, so that I can address it.
> 
> The updates are similar to the last patch series in that some functions
> took integers previously, but now they take floating-point values. In a
> number of cases, this patch series makes available both flavors: integer
> and floating-point. Is this what you had in mind?
> 
> And two more related points:
> 
> 1. This patch uncovered an inconsistency in much of our code: when
> converting a floating-point terminal coordinate to an integer one,
> sometimes we round (either with (int)(x+0.5) or by calling
> axis_map_toint()) and sometimes we floor ( (int)(x) ). Looks like it's
> more or less random which one we pick. We should always round, I
> suspect. This patch series doesn't attempt to resolve this, but a future
> set of patches should.

Your patch set definitely runs aground on that point.
I tried to compare results before/after the patches but there are so many
single-digit coordinate changes throughout that it's impossible.
Yes it may be worth it to review the double->termcoord conversion 
everywhere in the program, but let's disentangle that from changes to
handling short vectors.

Here's how I tested:
    ./gnuplot-before -e 'set term post color' all.dem < /bin/yes > all_before.ps
    ./gnuplot-after -e 'set term post color' all.dem < /bin/yes > all_after.ps

    diff -ur all_before.ps all_after.ps > all.diff
    diffstat all.diff

    diffstat all.diff
     all_after.ps |234431 +++++++++++++++++++++++++++++++-----------------------------
     1 file changed, 121820 insertions(+), 112611 deletions(-)

Ugh. Too many differences to evaluate in detail.  So I tried to back out all
the changes to existing coordinate routines and instead provide totally
separate routines to be called only along the new clip_arrow code path.
This reduced the background single-pixel changes a bit, but I must have
missed some places because are still a very large number of single-pixel
differences.

     diff -ur all_before.ps all_version2.ps > all_v2.diff
     diffstat all_v2.diff
     all_version2.ps |59388 +++++++++++++++++++++++++++++++++--------------------------
     1 file changed, 34040 insertions(+), 25348 deletions(-)

That let me look for problem areas, and I found some.
There are many cases where the coordinates passed to the terminal
driver have overflowed.  For example the "Let's smile with parametric filled curves" plot
in the filledcurves demo ends like this:

    gsave [] 0 setdash
    3980 1811 M
    0 -221 V
    -218 37 V
    -653259491 771754262 M
    3980 1590 L
    stroke
    grestore

The coordinates in that last move (M) command are nonsense.
This is also evident in the *.ps output from the Gantt chart demo.
Note that this demo seems to display correctly on the Qt termimal.
That might mean there's a postscript-specific bug or it might
be different terminal scale factors, or different terminal clipping
policies, or something else.

However, my quick hack to separate the generic and arrow-specific
effects of your patches may have introduced its own bugs.  
So I think I will hand it back to you to debug my debugging :-)

	Ethan


> 2. I discovered the issue with the vector fields manifests in two
> different ways. For very short vectors, they simply disappear, as we
> discussed. For vectors that are short, but not 0-pixels-short, the
> arrowheads are still plotted, but the angular resolution becomes very
> poor. The patches here resolve both of these.
> 
> 
> Thanks.
> 
>