gnuplot-beta

Gnuplot win terminal regression

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

Bastian:

Back in June I applied a patch from you that had the following ChangeLog
entry:

2008-06-24  Bastian Maerkisch  <bma...@we...>
        * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
        if it has only a single segment.

There is now a report on the newsgroup that for data files containing 
multiple polyline definitions (e.g. blank lines in the file), each supposedly
independent polyline is connected to the previous one.  From inspection of
the code, I conclude this is due to your change above.  That is, the initial
move command sets polyi=1, but your change causes this to be treated as a
length 1 polyline rather than a move.   Strangely, this happens only for
plots with either "... lc rgb variable" or "... lt palette z".
I don't fully understand why the linetype makes a difference.

Could you have another look at this issue please?  Perhaps the previous
patch should be reverted, or perhaps an additional fix is needed somewhere
in the W_pm3d_setcolor code block in wgraph.c.

I'd like to release an incremental version 4.2.4 sometime soon, and this
is the only regression I know of that would hold it up.

	Ethan

-- 
Ethan A Merritt

about incremental version 4.2.4

[Tatsuro M. <tma...@ya...>]

Hello Ethan A Merritt 

In your mail to Bastian, I found.

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.

Are you planning to add mouse zooming faclities for volatile data which is experimentally managed  in
cvs version (gnuplot 4.3) ?

As a octave user, I would like to manage this facilities in the gnuplot 4.2.4.

Regards

Tatsuro  


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: about incremental version 4.2.4

[Tatsuro M. <tma...@ya...>]

Hello

In my previous mail, English is too poor to reead. 
I will revise as possible as I can.

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

Hello Ethan A Merritt 
 
 In your mail to Bastian, I found.
 
 --- Ethan A Merritt <merritt@u.washington.edu> wrote: 
> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.
 
Are you planning to add mouse zooming feature for volatile data which is experimentally
embeded in cvs version (gnuplot 4.3) ?

 As an octave user, it is better that the mouse zooming feature for volatile data is to be embeded in
the gnuplot 4.2.4.

Regards
 
Tatsuro  
 
 
> --------------------------------------
> Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
> http://pr.mail.yahoo.co.jp/mlb/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: Gnuplot win terminal regression

[Bastian M. <bma...@we...>]

I found out what's happening:

In case of "lt palette z" and "lc rgb variable" there's a
polygon with the same start and endpoint. Windows optimizes this away 
and the drawing position is not updated. The next call to W_vect
therefore uses the wrong starting point.

Possible fixes:
a) a MoveTo() at every W_move call
b) a MoveTo() after all Polyline calls
c) filter out such polygons and replace by calls to MoveTo()


I'd prefer option b) because it is straightforward and does not 
introduce many additional GDI calls:

	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;
	}



   Bastian


Ethan A Merritt schrieb:
> Bastian:
> 
> Back in June I applied a patch from you that had the following ChangeLog
> entry:
> 
> 2008-06-24  Bastian Maerkisch  <bma...@we...>
>         * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
>         if it has only a single segment.
> 
> There is now a report on the newsgroup that for data files containing 
> multiple polyline definitions (e.g. blank lines in the file), each supposedly
> independent polyline is connected to the previous one.  From inspection of
> the code, I conclude this is due to your change above.  That is, the initial
> move command sets polyi=1, but your change causes this to be treated as a
> length 1 polyline rather than a move.   Strangely, this happens only for
> plots with either "... lc rgb variable" or "... lt palette z".
> I don't fully understand why the linetype makes a difference.
> 
> Could you have another look at this issue please?  Perhaps the previous
> patch should be reverted, or perhaps an additional fix is needed somewhere
> in the W_pm3d_setcolor code block in wgraph.c.
> 
> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.
> 
> 	Ethan
> 

Re: Gnuplot win terminal regression

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

On Wednesday 03 September 2008, Bastian Maerkisch wrote:
> I found out what's happening:
> 
> In case of "lt palette z" and "lc rgb variable" there's a
> polygon with the same start and endpoint. 

How does that happen?  Is this the real bug?

> Windows optimizes this away  
> and the drawing position is not updated. The next call to W_vect
> therefore uses the wrong starting point.
> 
> Possible fixes:
> a) a MoveTo() at every W_move call
> b) a MoveTo() after all Polyline calls
> c) filter out such polygons and replace by calls to MoveTo()
> 
> 
> I'd prefer option b) because it is straightforward and does not 
> introduce many additional GDI calls:
> 
> 	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;
> 	}

I don't understand why that would fix it, as it still looks to me from
reading the code that every move command has the potential to trigger 
the (polyi == 1) case.   But if you have tested it, then fine.

	Ethan 


> 
> 
>    Bastian
> 
> 
> Ethan A Merritt schrieb:
> > Bastian:
> > 
> > Back in June I applied a patch from you that had the following ChangeLog
> > entry:
> > 
> > 2008-06-24  Bastian Maerkisch  <bma...@we...>
> >         * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
> >         if it has only a single segment.
> > 
> > There is now a report on the newsgroup that for data files containing 
> > multiple polyline definitions (e.g. blank lines in the file), each supposedly
> > independent polyline is connected to the previous one.  From inspection of
> > the code, I conclude this is due to your change above.  That is, the initial
> > move command sets polyi=1, but your change causes this to be treated as a
> > length 1 polyline rather than a move.   Strangely, this happens only for
> > plots with either "... lc rgb variable" or "... lt palette z".
> > I don't fully understand why the linetype makes a difference.
> > 
> > Could you have another look at this issue please?  Perhaps the previous
> > patch should be reverted, or perhaps an additional fix is needed somewhere
> > in the W_pm3d_setcolor code block in wgraph.c.
> > 
> > I'd like to release an incremental version 4.2.4 sometime soon, and this
> > is the only regression I know of that would hold it up.
> > 
> > 	Ethan
> > 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742