Re: Short vectors are not plotted

[sfeam <sf...@us...>]

On Sunday, 29 October 2017 16:02:11 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> >> I.e. we convert the vector start/end to integer terminal coords; short
> >> vectors become 0-vectors in this representation, so the
> >> terminal-specific arrow() function plots nothing.
> >>
> >> This is a bug: checking for a 0-vector should happen before we convert
> >> to integer pixel coordinates.
> >
> > I am not following the logic.
> >
> > If it is a 0-length vector then isn't it correct to not draw it?
> > Even if you keep the floating point representation for a bit longer,
> > at the time you convert to integer terminal coordinates it will
> > again become 0-length and thus not drawn.  What am I missing?
> >
> > Is the idea that you want to draw an arrowhead even if the
> > shaft length is zero?
> 
> Right. It's not actually a length-0 vector, but its length is < 1 pixel
> long. We should still draw an arrowhead, and the arrowhead should point
> in the correct direction. Once we convert to integers, then even if we
> wanted to draw something, we can't do it, since the direction has been
> lost.

I don't at all like the idea of mixing (double) and (int) coordinates in the
terminal API.  Let's try to find a different solution.

First off, I think your patch only handles a subset of arrows.
It modifies the handling of "plot ... with vectors" but not the code that
handles "splot ... with vectors" or "set arrow ...".

That last one is interesting because rather than the in-line coordinate
transform and clipping code used by plot_vectors() and plot3d_vectors()
it goes through a much simpler routine draw_clip_arrow(). 
And it looks to me at first glance that the bulk of the former two code
blocks can be replaced by a call to draw_clip_arrow() also.
That at least brings all the arrow-drawing onto a common path.

Next I note that most of the callers of draw_clip_arrow are already
working with (double) coordinates. Converting the remaining ones
should be relatively simple.

At that point I think you are mostly home free. Now all you need to
do is add a flag or a new set of enums to the 5th parameter of 
do_arrow() that signals "draw only the arrowhead".   In places where
you want to guarantee that the arrowhead is drawn even if the vector
length approaches zero, you can call term->arrow() twice.
The first call is either exactly like now or perhaps we would clear
all the arrowhead flags.
The second call we dummy up a unit length vector in the desired
direction  but set the "arrowhead only" flag.

And that should do it except for the oddball terminals that have
private arrow-drawing code.  Leave that to a second round of cleanup
after the generic code path is working.

	Ethan


> 
> Here's a (hopefully convincing) thought: let's say you're looking at a
> plot of a vector field. Then you zoom out repeatedly. I would expect the
> plotted vector lengths to get shorted as you zoom out. The arrowheads
> maybe would get smaller too, depending on how they're plotted. But the
> transitions should be smooth. What currently happens is that as you zoom
> out, some subset of the vectors disappears. As you zoom out more, some
> OTHER subset disappears. This subset could be entirely different, and
> some vectors actually come back. Eventually they all disappear, but as
> they do so, sometimes they're plotted in an intermediate state where the
> arrowhead IS plotted, but its direction is completely wrong.
> 
> Try with the example attached in the last email; use the mouse wheel to
> zoom out.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta