Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-22 20:50:27
|
Hello, everyone, as your should have noticed from the flurry of status change mails that went by on the gnuplot-developers mailing list (you *are* all subscribed to that, aren't you?), I went over the currently open bugs and (rather subjectively) selected those which I would consider release-criticial, i.e. which really have to be settled one way or the other before we can confidently claim to have a version worthy of being released to the general public. To keep track of which those bugs are, I added a "Group" called "release_critical" in the bug tracker. You can narrow down the view of open bugs by selecting that from the drop-down menu. If you consider any of the existing bugs release-critical, you can mark them accordingly. After going over those I marked one by one, there's currently only one such bug left (X11 rotated text on unusual platforms...), which I've assigned to Ethan, since he claimed at one point in time to have reproduced the misbehaviour and understood the patch, too. We won't release unless all bugs have either been resolved+closed, or we have agreed that they're not all that critical right at this time. E.g. I personally don't consider lack of any optional feature by any terminal driver a critical bug that should delay the release. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-02-23 01:15:59
|
On Sunday 22 February 2004 12:42 pm, Hans-Bernhard Broeker wrote: > > After going over those I marked one by one, there's currently only one > such bug left (X11 rotated text on unusual platforms...), which I've > assigned to Ethan, since he claimed at one point in time to have > reproduced the misbehaviour and understood the patch, too. I will apply the fix, but I remind you that there is a trade-off involved. The current bug can be described: "If you use a non-white background in the X11 terminal, then rotated text may cause nearby elements to be drawn in the wrong color" I am not aware of any platform dependence. The bug is only triggered by having a background color that is not pure white. With the patch applied there is no problem with colors, but any x11 plot containing rotated text is refreshed very much slower. This is in particular noticeable when you resize the plot window. But speeding up window resizing is certainly not release-critical, so we can address it later. > We won't release unless all bugs have either been resolved+closed, or we > have agreed that they're not all that critical right at this time. E.g. I > personally don't consider lack of any optional feature by any terminal > driver a critical bug that should delay the release. Agreed. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Dave D. <dde...@es...> - 2004-02-23 13:58:08
|
Ethan A Merritt <merritt@u.washington.edu> writes: > On Sunday 22 February 2004 12:42 pm, Hans-Bernhard Broeker wrote: >> >> After going over those I marked one by one, there's currently only one >> such bug left (X11 rotated text on unusual platforms...), which I've >> assigned to Ethan, since he claimed at one point in time to have >> reproduced the misbehaviour and understood the patch, too. > > I will apply the fix, but I remind you that there is a trade-off involved. > The current bug can be described: > "If you use a non-white background in the X11 terminal, then > rotated text may cause nearby elements to be drawn in the > wrong color" > I am not aware of any platform dependence. The bug is only > triggered by having a background color that is not pure white. > > With the patch applied there is no problem with colors, but any > x11 plot containing rotated text is refreshed very much slower. > This is in particular noticeable when you resize the plot window. > But speeding up window resizing is certainly not release-critical, > so we can address it later. > Sorry, I'm way out of date with gnuplot... what's the change, and why does it cause a slowdown ? dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-02-23 19:59:55
|
On Monday 23 February 2004 05:48 am, Dave Denholm wrote: > > With the patch applied there is no problem with colors, but any > > x11 plot containing rotated text is refreshed very much slower. > > This is in particular noticeable when you resize the plot window. > > But speeding up window resizing is certainly not release-critical, > > so we can address it later. > > what's the change, and why does it cause a slowdown ? The previous code assumed that text/background pixel area could be represented by a 1-bit deep array. The array was rotated, and then the entire rotated array was ORer back onto the original image in one (relatively fast) operation. The problem is that ORing the background color is only harmless if it is represented by all zeros. If it is anything else then the OR operation perturbs the existing colors. The new code explicitly tests for pixels in the rotated text box that are non-background, and substitutes them back into the original image one by one. That is relatively slow. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center (206)543-1421 Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Dave D. <dde...@es...> - 2004-02-23 19:59:46
|
Ethan Merritt <merritt@u.washington.edu> writes: > On Monday 23 February 2004 05:48 am, Dave Denholm wrote: >> > With the patch applied there is no problem with colors, but any >> > x11 plot containing rotated text is refreshed very much slower. >> > This is in particular noticeable when you resize the plot window. >> > But speeding up window resizing is certainly not release-critical, >> > so we can address it later. >> >> what's the change, and why does it cause a slowdown ? > > The previous code assumed that text/background pixel area could > be represented by a 1-bit deep array. The array was rotated, and > then the entire rotated array was ORer back onto the original image > in one (relatively fast) operation. The problem is that ORing the > background color is only harmless if it is represented by all zeros. > If it is anything else then the OR operation perturbs the existing > colors. > > The new code explicitly tests for pixels in the rotated text box that > are non-background, and substitutes them back into the original > image one by one. That is relatively slow. > Yes, that's what I feared... isn't the standard trick here to first AND with bg = ~0, fg = reqd colour then OR with bg = 0, fg = reqd colour true there may be an intermediate frame with the wrong foreground colour, but it's usually not noticable. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Dave D. <dde...@es...> - 2004-02-24 10:23:04
|
Ethan Merritt <merritt@u.washington.edu> writes: > I was hoping for a more general solution, or rather a solution > that would help all redrawing of all x11 plot windows. The bigger > problem is that the window is redrawn repeatedly during and > after resizing. Having the individual redraws a bit slow is less of > a concern than the fact that it may redraw 10 times when only > 1 or 2 were really necessary. > Doesn't this depend on the window manager configuration ? If the user has set the window manager to continuous redraws during resize, then that's exactly what they want the behaviour to be. So the redraws are not unnecessary. I seem to be setup to use rubber-banding during resizing, so I wouldn't expect to get any intermediate redraws. (But maybe I misunderstood the problem.) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Dave D. <dde...@es...> - 2004-02-24 10:23:13
|
Ethan Merritt <merritt@u.washington.edu> writes: > I was hoping for a more general solution, or rather a solution > that would help all redrawing of all x11 plot windows. The bigger > problem is that the window is redrawn repeatedly during and > after resizing. Having the individual redraws a bit slow is less of > a concern than the fact that it may redraw 10 times when only > 1 or 2 were really necessary. > Doesn't this depend on the window manager configuration ? If the user has set the window manager to continuous redraws during resize, then that's exactly what they want the behaviour to be. So the redraws are not unnecessary. I seem to be setup to use rubber-banding during resizing, so I wouldn't expect to get any intermediate redraws. (But maybe I misunderstood the problem.) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Dave D. <dde...@es...> - 2004-02-24 10:23:48
|
Ethan Merritt <merritt@u.washington.edu> writes: > I was hoping for a more general solution, or rather a solution > that would help all redrawing of all x11 plot windows. The bigger > problem is that the window is redrawn repeatedly during and > after resizing. Having the individual redraws a bit slow is less of > a concern than the fact that it may redraw 10 times when only > 1 or 2 were really necessary. > Doesn't this depend on the window manager configuration ? If the user has set the window manager to continuous redraws during resize, then that's exactly what they want the behaviour to be. So the redraws are not unnecessary. I seem to be setup to use rubber-banding during resizing, so I wouldn't expect to get any intermediate redraws. (But maybe I misunderstood the problem.) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-02-26 17:39:20
|
Oh yeah, what about this issue with the arrowhead tips extending past
the point specified in the data? I guess I'm in the camp that says that
should be fixed so that the arrowhead tip ends right at the data point
specified. It would be nice to not let people get into the habit of
compensating for that themselves and then to later have it changes. I
wrote out the formula and was going to write a patch, but unfortunately
there was nowhere that I could get the line thickness from.
Could it be kludged in some way? That is, could we add a terminal
routine (dread!) that returns the width of the line and then in the
terminal function just do some trial and error guesstimating about the
line thickness? That is, the formula for the vector to compensate is
v = - SE * w / (2 |SE| sin(alpha))
where SE is the vector in terms of start and end position, alpha is the
angle of the arrow command, and w is the width of the current line.
Since line widths are a unitless number, I assume that each terminal
needs a different routine, e.g.,
w = term->linewidth( unitless_width );
Where w is the width in appropriate graph units. Or maybe the linewidth
could be an array entry in other terminal characteristics. For now,
maybe the values could be fudged by trial and error. E.g.,
float PS_linewidth( unitless_width ) {
/* Do a crude linear approximation for now. */
return unitless_width * TRIAL_AND_ERROR_PARAMETER;
}
Any thoughts on what to do here?
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-02-26 18:12:43
|
On Thursday 26 February 2004 09:57 am, Daniel J Sebald wrote: > Oh yeah, what about this issue with the arrowhead tips extending past > the point specified in the data? I guess I'm in the camp that says that > should be fixed so that the arrowhead tip ends right at the data point > specified. It would be nice to not let people get into the habit of > compensating for that themselves and then to later have it changes. I am opposed to touching this before a version 4 release. It falls into the area of aesthetics and philosophy rather than bug-fixing. I don't want to rehash the whole discussion now, but I suggest that long-term the best fix is to have an arrow drawing mode that works by building the arrow out of filled rectangles and filled triangles. That way you could specify thin lines but a solid fill and I think everyone would be happy with the resulting plot. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center (206)543-1421 Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-02-26 18:39:08
|
Ethan Merritt wrote: >On Thursday 26 February 2004 09:57 am, Daniel J Sebald wrote: > > >>Oh yeah, what about this issue with the arrowhead tips extending past >>the point specified in the data? I guess I'm in the camp that says that >>should be fixed so that the arrowhead tip ends right at the data point >>specified. It would be nice to not let people get into the habit of >>compensating for that themselves and then to later have it changes. >> >> > >I am opposed to touching this before a version 4 release. >It falls into the area of aesthetics and philosophy rather than >bug-fixing. > It is a big change. Not a show-stopper. Dan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X