#1611 Redraw error on resizing window in x11 term (on mac at least)

[Anonymous]

Dear gnuplot team,

I recently upgraded my macports installation and am now running gnuplot 5.0 patchlevel 0 on Yosemite (xserver XQuartz 2.7.7 (xorg-server 1.16.4)).

I have found a minor bug with the x11 terminal: upon resizing the window, the new plot does not always fill the new window size, but gets sometimes stuck at the old window size, somehow particularly when the lower right corner is being dragged upwards. (Seems like a dropped xevent somewhere?)

In any case, typing "e" into the window to force a replot fixes the problem, but I thought it might be worthwhile to report it.

BTW, I like the new x11 terminal line colors.

Thanks,
Gary

[Torquil Macdonald Sørensen]

I'm experiencing the same thing on Linux. Typing "e", or indeed using any arrow key or performing a slight rotation with the mouse causes a replot that fixes the problem.

$ cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.1 (Maipo)

$ gnuplot --version
gnuplot 5.0 patchlevel 0

[Karl Ratzsch]

Same here on xubuntu with 5.0-cvs.
The 5.0-rc2 binary version from debian backports does not show the problem, btw. Seems to have occurred sometime late last year. From a quick look at the changelog, i'd suspect it happened on 2014-12-15.

[Dan Sebald]

The 2015-12-15 changelog indicates that both Qt and X11 terminals were modified. Is Qt term resize functioning correctly in the CVS repository head?

Qt seems to work here, but I do notice one strange thing. When I drag the lower right corner of the window very quickly there appears to be some intermediate draw having a very distorted size. For example, a small window expanded big quickly will show an intermediate size plot and then jump back to a small plot before plotting the correctly sized plot. Another example is going from large plot window to small. In the mix is a plot for which the font size is extremely large.

X11 terminal doesn't do this and appears to work well on my system.

[Dan Sebald]

Here's something I notice in X11 term. If a slow plot is created, say:

set term x11
set isosamples 500
splot x**2*y**3 with lines

dragging the lower right corner about for five to ten seconds and then position the mouse inside the window will show the cursor bouncing between busy and non-busy for five seconds. There must be mouse events queued that all cause a redraw even though they are all using the same window size for the final five seconds. It might make sense to discard mouse move events until a non-mouse move event is reached or the queue is empty and then redraw.

[Ethan Merritt]

Supposedly it is doing that (discarding outdated events) already. But it may well be that some classes of events are not caught by this bit of code in gplt_x11.c. Maybe you can add some debug statements to capture which events are backed up?

        /* Check for any ConfigureNotify events further down in the X11
         * event queue. If one is found, handle it first and let the
         * expose event that is generated be handled later.
         * Jay Painter Nov 2003.
         */
        if (XCheckTypedWindowEvent(dpy, event->xany.window, ConfigureNotify, event)) {
            process_configure_notify_event(event, FALSE);
            break;
        }
        while (XCheckTypedWindowEvent(dpy, event->xany.window, Expose, event));

[Dan Sebald]

Well, based upon some fprintf(stderr,) inside and outside the conditional and the while loop:

    if (XCheckTypedWindowEvent(dpy, event->xany.window, ConfigureNotify, event)) {
        process_configure_notify_event(event, FALSE);
        break;
    }
    while (XCheckTypedWindowEvent(dpy, event->xany.window, Expose, event));

the program flow never goes inside the conditional (never any ConfigureNotify), and the only time that the while loop is executed is when the X window comes back into focus. There are five Expose events in the queue whenever the X window is brought back into focus. So four of those are being discarded, but that is it.

I don't know how this Expose case is called for every draw if it doesn't relate to resizing the window. I'll keep looking...

[Dan Sebald]

OK, a little more information. I printed out every XEvent that comes in and eventually determined that it isn't the XEvents that are being accumulated. There are some spurious XEvents after I finish dragging the bottom-right corner about, but they soon stop afterward. These two:

#define SelectionClear      29
#define SelectionRequest    30

They aren't a problem as I see it, or are the consequence of the real problem.

What is happening is that the display() routine keeps getting called via the record() function somehow. It is this one:

    case 'E':       /* leave graphics mode / suspend */
        if (plot)
{
fprintf(stderr, "DISPLAY #26\n");
        display(plot);
}

where I see:

dpy=27801952, xany.window=79691915, event_type=22, event=140736894077408
Finding plot...
Plotting...
EVENT=22 any 0
EVENT=12 any 0
dpy=27801952, xany.window=79691915, event_type=22, event=140736894077408
Finding plot...
Plotting...
[Up to this point is pretty near when I stop moving mouse]
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26
DISPLAY #26

So, you can see that something is putting 'E' into a record buffer. Any ideas?