Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Ethan M. <merritt@u.washington.edu>]

On Monday 08 September 2008 11:34:24 Bastian Maerkisch wrote:
> 
> Ethan Merritt schrieb:
> > 
> > But I see that the bug demonstrated by the attached script is still present.
> > I have reverted in CVS the patch that I suspect is responsible.
> 
> > Bastian Maerkisch is looking into the problem, but until we have a more solid
> > fix I think reversion is best.
> > 
> > Petr:
> > Could you test whether the latest CVS (just changed a few minutes ago) fixes
> > the win terminal bug as tested by the attached script?
> > 
> > Bastian:
> > The original patch that I have reverted looks wrong to me, now that I have
> > stared at the code.  Do you have a script that demonstrates the problem it
> > was originally intended to fix?  So far as I can see, there should be no
> > path through the code that produces a "polyline of length 1".  The vertex
> > counter starts at 1, and each polyline vector call increases it.  So 
> > (polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
> > But maybe it should execute a MoveTo()?
> > 
> 
> Ethan, your conclusion is not correct.
> 
> Polylines are drawn with commands like this:
> MOVE, VECTOR, VECTOR, VECTOR, VECTOR, ...
> The code defines the end of a polyline if the next command is not VECTOR.

But after the first MOVE, polyi is *already* equal to 1.
The (polyi == 1) case corresponds to no VECTORs at all.
A length 1 polyline must necessarily have (polyi == 2).

> In the case of RGB color lines there actually are length 1 polylines. 
> That's because they are drawn with commands like like that:
> MOVE, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
  ^^^^ polyi = 1
               ^^^^^^ polyi = 2

> The fix, which you just reverted, fixes this.

I'm working blind, since I can't actually compile and test this.
But I sure don't see from the code how you can ever have a polyline
with (polyi == 1).

> The new bug is IMHO triggered by some ill-behaviour of the Windows API. 
> In the case you just send me the command sequence is like this:
> MOVE, VECTOR, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
> The first move and vector command reference the same point. The windows 
> API optimizes this away and does not even update the drawing position.

I don't understand what you are saying.  By "optimize away" do you mean
"ignores both the move and the vector"?  That would be a serious bug indeed.
It seems especially strange the the optimization would only occur if there
is an intervening call to COLOR (remember that the error is not triggered
if the line color is constant).

What exactly does "COLOR" mean in that sequence?
Is it a call to to W_pm3d_setcolor, or is it an actual API call?

> So with the next VECTOR we get "spurious" lines.
> 
> Why don't you try the single line fix I sent to the mailing list? We 
> hist add an additional MoveTo() after each Polyline, like this:
> 
> if ((lastop==W_vect) && (curptr->op!=W_vect)) {
> 	    if (polyi >= 2) {
> 		Polyline(hdc, ppt, polyi);
> 		MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y);  /* make sure we move the 
> drawing position in case of empty polygons */
> 	    } else if (polyi == 1)
> 		LineTo(hdc, ppt[0].x, ppt[0].y);
> 	    polyi = 0;
> 	}

You've tested that this fixes the bug show by the test script?

I may be more than usually befuddled, but I just don't understand how it could.
If there is a spurious line, then you will have already drawn it
before you call the MoveTo.

For what it's worth, the test case *should* be generating a sequence like
COLOR MOVE VECTOR COLOR MOVE VECTOR COLOR MOVE VECTOR
Possibly with interspersed calls to W_linetype, although they are supposed to
be optimized away at a higher level.

If it's not doing that, then I think the true bug may lie entirely elsewhere. 
You said earlier that the calls to WIN_set_color were generating empty polylines,
but only in the case of variable color.  Doesn't that seem strange?

-- 
Ethan A Merritt