Menu
▾
▴
gnuplot-beta
|
From: Dima K. <gn...@di...> - 2013-04-07 11:34:16
Attachments:
tst.gp
|
Hi all.
I'm seeing an intermittent error that happens when plotting an image
with the x11 terminal. To reproduce:
- Fresh checkout of gnuplot
- $ ./prepare && ./configure && make -j2
- $ export GNUPLOT_DRIVER_DIR=$PWD/src
- $ src/gnuplot /tmp/tst.gp
The data file is attached (it's mostly the same as the one in an
unrelated email a few days ago). Normally, that command will make a plot
and exit immediately; the plot window should quickly flicker. There is a
bug, however, that causes this plot command to fail occasionally. If I
run that last command repeatedly, I sometimes get
GNUPLOT (gplt_x11): Couldn't read image parameters correctly.
When this error pops up, the resulting plot is generally corrupt. The
error happens much more readily if the plot window comes up under the
mouse cursor. I'm using a more-or-less stock Debian/unstable box, and I
see this error often, even when I'm using gnuplot to get work done, not
just trying to coax out the bug.
I dug into this, and I see what's happening. There's quite a bit of
state in gplt_x11.c and it doesn't all stay in sync all the time. The
image is transferred into gplt_x11.c from gnuplot itself using lots of
'i' commands. The bug occurs when an X EnterNotify event is received,
and causes display() to be called in the middle of the image transfer.
The display() then processes all the 'i' commands that have come through
so far; not all of them arrived yet, so it doesn't actually draw
anything. There is state in processing the 'i' commands, however. This
state is normally reset when the last 'i' command is processed to
complete the image. Here, we never completed the image, so the state is
never reset, and gnuplot is confused the next time display() is called
when all the data is finally available. The static variables in question
are in exec_cmd() in this block:
else if (*buffer == X11_GR_IMAGE) { /* image */
static unsigned char *iptr;
static TBOOLEAN transferring = 0;
static unsigned short *image;
static int M, N;
static int pixel_1_1_x, pixel_1_1_y, pixel_M_N_x, pixel_M_N_y;
static int visual_1_1_x, visual_1_1_y, visual_M_N_x, visual_M_N_y;
static int color_mode;
static unsigned int i_remaining;
There are multiple ways to address this, so I'm not making fixes yet. We
could disallow calling display() with incomplete data, or we could reset
the state at the start of the display() call. As a separate comment,
making this less stateful and simplifying the image transfer would be a
great thing to do in either case, I think.
Is any particular approach favored here?
dima
|
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-07 22:48:31
|
On Sunday, 07 April 2013, Dima Kogan wrote:
> Hi all.
>
> I'm seeing an intermittent error that happens when plotting an image
> with the x11 terminal. To reproduce:
>
> - Fresh checkout of gnuplot
> - $ ./prepare && ./configure && make -j2
> - $ export GNUPLOT_DRIVER_DIR=$PWD/src
> - $ src/gnuplot /tmp/tst.gp
>
> The data file is attached (it's mostly the same as the one in an
> unrelated email a few days ago). Normally, that command will make a plot
> and exit immediately; the plot window should quickly flicker. There is a
> bug, however, that causes this plot command to fail occasionally. If I
> run that last command repeatedly, I sometimes get
>
> GNUPLOT (gplt_x11): Couldn't read image parameters correctly.
>
> When this error pops up, the resulting plot is generally corrupt. The
> error happens much more readily if the plot window comes up under the
> mouse cursor. I'm using a more-or-less stock Debian/unstable box, and I
> see this error often, even when I'm using gnuplot to get work done, not
> just trying to coax out the bug.
>
> I dug into this, and I see what's happening. There's quite a bit of
> state in gplt_x11.c and it doesn't all stay in sync all the time. The
> image is transferred into gplt_x11.c from gnuplot itself using lots of
> 'i' commands. The bug occurs when an X EnterNotify event is received,
> and causes display() to be called in the middle of the image transfer.
> The display() then processes all the 'i' commands that have come through
> so far; not all of them arrived yet, so it doesn't actually draw
> anything. There is state in processing the 'i' commands, however. This
> state is normally reset when the last 'i' command is processed to
> complete the image. Here, we never completed the image, so the state is
> never reset, and gnuplot is confused the next time display() is called
> when all the data is finally available. The static variables in question
> are in exec_cmd() in this block:
>
> else if (*buffer == X11_GR_IMAGE) { /* image */
>
> static unsigned char *iptr;
> static TBOOLEAN transferring = 0;
> static unsigned short *image;
> static int M, N;
> static int pixel_1_1_x, pixel_1_1_y, pixel_M_N_x, pixel_M_N_y;
> static int visual_1_1_x, visual_1_1_y, visual_M_N_x, visual_M_N_y;
> static int color_mode;
> static unsigned int i_remaining;
>
>
> There are multiple ways to address this, so I'm not making fixes yet. We
> could disallow calling display() with incomplete data, or we could reset
> the state at the start of the display() call. As a separate comment,
> making this less stateful and simplifying the image transfer would be a
> great thing to do in either case, I think.
>
> Is any particular approach favored here?
I am not familiar with the code, but from your description I'd say that
the proper approach is to accumulate the image data in a separate
buffer and only link it into the display buffer when the transfer
has completed. If the the code already does that and the problem
happens anyhow, then events (or at least event handling) need to
be locked out while the display buffer is being modified.
Strange that no one has reported this problem before now.
On the other hand, I had a very hard time reproducing it with your
test case. I must have tried 50 times before I saw a single failure.
So maybe it's just very rare. Or maybe something on your machine
configuration makes it unusually prone to this error.
Or maybe hardly anyone is using x11 anymore. I know I strongly prefer
either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix
this if possible, but the reality is that I view the x11 terminal as having
been superseded by newer, more capable terminal options. There
are many things that it just doesn't handle very well (font scaling,
non-ascii encodings, transparency, anti-aliasing, ...).
Ethan
>
> dima
>
>
|
|
From: Jonathan T. <jt...@as...> - 2013-04-07 23:14:20
|
On Sun, 7 Apr 2013, Ethan Merritt wrote:
> Or maybe hardly anyone is using x11 anymore. I know I strongly prefer
> either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix
> this if possible, but the reality is that I view the x11 terminal as having
> been superseded by newer, more capable terminal options. There
> are many things that it just doesn't handle very well (font scaling,
> non-ascii encodings, transparency, anti-aliasing, ...).
I very much hope we retain full support for the x11 terminal. x11 is
(and remains) my strongly-preferred interactive terminal for two key
reasons:
* x11 builds easily & cleanly even if 3rd-party libraries are broken
or live in odd places
* x11 respects X resource specifications in ~/.Xdefaults
(e.g. I have the line "gnuplot*reverseVideo: on" there, so x11 comes
up with a black background. wxt ignores that and comes up with a white
background which I find ugly. I don't know what qt does.)
ciao,
--
-- Jonathan Thornburg <jt...@as...>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
on sabbatical on Thetis Island, BC, Canada starting August 2012
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-07 23:40:12
|
On Sunday, 07 April 2013, Jonathan Thornburg wrote: > On Sun, 7 Apr 2013, Ethan Merritt wrote: > > Or maybe hardly anyone is using x11 anymore. I know I strongly prefer > > either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix > > this if possible, but the reality is that I view the x11 terminal as having > > been superseded by newer, more capable terminal options. There > > are many things that it just doesn't handle very well (font scaling, > > non-ascii encodings, transparency, anti-aliasing, ...). > > I very much hope we retain full support for the x11 terminal. Sure, for a definition of "full support" that includes acknowledging that the x11 terminal doesn't provide the entire current set of features. > x11 is (and remains) my strongly-preferred interactive terminal for two key > reasons: > * x11 builds easily & cleanly even if 3rd-party libraries are broken > or live in odd places I can see that being an advantage if you find yourself having to rebuild from source on lots of different machines. It doesn't count for much in cases where you can run pre-built binaries, whether they were provided by a distro or self-built on a fully-configured machine for deployment on less completely configured machines like in a computer lab. > * x11 respects X resource specifications in ~/.Xdefaults > (e.g. I have the line "gnuplot*reverseVideo: on" there, so x11 comes > up with a black background. wxt ignores that and comes up with a white > background which I find ugly. I don't know what qt does.) The qt terminal provides a widget for selecting the background color. The choice is saved in ~/.qt/qtrc. Current gnuplot allows you to place linetype preferences in your ~/.gnuplot initialization file, which is a more general solution than using X resources. Ethan > ciao, > > |
|
From: Dima K. <gn...@di...> - 2013-04-08 10:41:38
|
Ethan Merritt <merritt@u.washington.edu> writes: > On Sunday, 07 April 2013, Dima Kogan wrote: >> Hi all. >> >> I'm seeing an intermittent error that happens when plotting an image >> with the x11 terminal. I'm attaching two patches to fix this. I simply send a new command to indicate the end of an image block, and the plotter now doesn't try to process any commands in the middle of an image block. > Strange that no one has reported this problem before now. > On the other hand, I had a very hard time reproducing it with your > test case. I must have tried 50 times before I saw a single failure. > So maybe it's just very rare. Or maybe something on your machine > configuration makes it unusually prone to this error. I use a tiling window manager (notion), and I suspect this is the reason. In any case, this was undeniably a bug. > Or maybe hardly anyone is using x11 anymore. I know I strongly prefer > either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix > this if possible, but the reality is that I view the x11 terminal as having > been superseded by newer, more capable terminal options. There > are many things that it just doesn't handle very well (font scaling, > non-ascii encodings, transparency, anti-aliasing, ...). My only reason for sticking with x11 is performance. Last year I tried wxt and qt, and they were both noticeably more sluggish. I just tried it again, and while qt was very slow, wxt seemed about as fast as x11. So maybe I'll jump ship too in a bit. dima |
